consider switching from manual indirect passing to byval

[thestinger]

If we did this, LLVM would generate the copy for us, but only if needed (not a readonly parameter). It also conveys more information to the body of the function, by letting it know the pointer is valid.

[pnkfelix]

I don't understand what this ticket is asking for. Is it about the code being generated by trans for LLVM to process, or is it actually proposing a deep change to the language itself?

[thestinger]

Just a codegen change (tagged properly now). We currently generate a copy in the caller ourselves for non-immediate values, and pass by-pointer. LLVM has a byval attribute to generate the copy for you from a pointer, although it might have ABI implications too (might be something we get wrong for foreign functions).

[nikomatsakis]

Makes sense, though I think we may also have more information than LLVM -- I've been wanting to optimize trans by passing in information about when a "by value" parameter can be used "in place". Though the ability to declare parameters as mut kind of throws a wrench into that, but I guess we can export whether parameters are declared as mut as part of the fn sig, used only for optimization purposes.

[nikomatsakis]

Still I tend to agree we should generate the most "semantically correct" LLVM bitcode that we can.

[huonw]

Isn't a parameter declared as mut just sugar? i.e. the following are equivalent:

fn foo(mut x: Type) { 
    ... 
}

fn bar(x: Type) {
    let mut x = x;
    ...
}

[nikomatsakis]

Isn't a parameter declared as mut just sugar? i.e. the following are equivalent:

Equivalent from the language POV, yes, but not necessarily the
codegen. I have to double check, though, whether or not a mut
parameter winds up being mutated in place or not. Certainly we could
ensure that this is not the case if we wanted, which would prob be
better than exporting whether or not a parameter is declared as mut.

[thestinger]

I don't think we should do this now that we have dereferenceable.