yaxunl added inline comments.
================
Comment at: lib/CodeGen/CGCall.h:211
+ push_back(CallArg(rvalue, type, needscopy, AS));
}
----------------
rjmccall wrote:
> 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.
Sorry for the delay. I updated the patch with by the second approach. I did not
add a member of LValue type to CallArg but added a member of Expr* type since
sometimes LValue is not available. The Expr is the l-value expression from
which the r-value is derived.
https://reviews.llvm.org/D34367
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
