arielb1
commented
8 years ago IRC log:
<pcwalton> is there any reason why we can’t just avoid the memcpy of outgoing arguments if the argument being moved is non-Copy and is on stack?
<pcwalton> if it’s being moved and is non-Copy then it’s guaranteed to be dead
<pcwalton> likewise, stack->stack moves of non-Copy should just be eliminated in trans, unless I’m missing something
<pcwalton> the value is guaranteed to be dead
<arielby> pcwalton: because writes
<pcwalton> can you elaborate?
<pcwalton> if I need to I could just add some checks for immutability too
<pcwalton> that’s easy
<arielby> pcwalton: btw, the MIR semantics
<arielby> can have always by-`&move` calls
<arielby> the MIR generated by mir builder is always like that
* niconii (nicole@moz-qjoals.midco.net) has joined
* ChanServ sets mode +a on #rustc niconii
* ChanServ gives channel operator status to niconii
<pcwalton> it’s silly to think that we can’t do this at MIR level
<pcwalton> LLVM is quite capable of doing this in many cases
<pcwalton> and LLVM’s handling of memory is the wild west compared to MIR
<arielby> yea
<arielby> trans::mir should not need to do a memcpy for arguments
<arielby> never
<pcwalton> ok, good
<arielby> even for Copy things
<pcwalton> I’ll work on this
<arielby> because MIR builder always does a copy
<pcwalton> I already have a WIP patch that is passing tests
<arielby> pcwalton: just be sure to notify nmatsakis on this
<arielby> eh I'll just write an issue on rust-memory-model
<pcwalton> that removes all memcpys when Store would do
<pcwalton> awesome, thank you! :)
<pcwalton> there are a lot of legacy cases in trans where we call llvm.memcpy unconditionally even for small types
<pcwalton> this just adds bitcasts and makes LLVM do more work for no reason
<pcwalton> btw, the criticisms of MIR being non-SSA that I occasionally hear don’t really make sense to me anymore
<pcwalton> LLVM isn’t really SSA either
<pcwalton> except for simple cases
<pcwalton> because anything in the real world requires memory analysis
<pcwalton> which is not SSA
<pcwalton> the greatest kept secret ;)
strega-nil
RalfJung
In MIR, function calls take a set of arguments. ABIs that take a function argument by-reference treat their arguments as scratch space.
If we don't want MIR trans has to copy the arguments to its own temps, we need to treat arguments moved into MIR calls as scratch space, at least for the duration of the call (even if they are non-
Copydata, such as[u8; 1024]).Because the current MIR generator always copies arguments to temps, this should not affect Rust semantics.
cc @nikomatsakis