rjmccall added inline comments.
================
Comment at: lib/CodeGen/CGCall.h:211
+ push_back(CallArg(rvalue, type, needscopy, AS));
}
----------------
Ah, I think I understand what's going on here now. "indirect byval" arguments
include an implicit copy to the stack, and the code is trying to avoid emitting
an extra copy to a temporary in the frontend. It does this by recognizing
loads from aggregate l-values and just adding the l-value to the call-argument
list as a "needs copy" argument. Call-argument preparation then recognizes
that the argument is being passed indirect byval and, under certain conditions,
just uses the l-value address as the IR argument.
Instead of creeping more and more information from the LValue into the CallArg,
I think there are two reasonable alternatives:
- Suppress this optimization in EmitCallArg when the LValue isn't in the alloca
address space. EmitCallArg already suppresses it when the argument is
under-aligned.
- Find a way to actually store an LValue in a CallArg. This has the advantage
that we can assert if someone tries to access it as an RValue, which is good
because any attempt to use a needs-copy argument as if it were a normal
argument is a lurking bug.
https://reviews.llvm.org/D34367
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
