[cfe-commits] r145736 - in /cfe/trunk/lib/CodeGen: CGClass.cpp CGException.cpp CGExpr.cpp CGExprCXX.cpp CGStmt.cpp CGValue.h CodeGenFunction.h

[John McCall]

On Dec 2, 2011, at 9:38 PM, Eli Friedman wrote:
> On Fri, Dec 2, 2011 at 8:33 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Fri, Dec 2, 2011 at 5:37 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Dec 2, 2011, at 4:54 PM, Eli Friedman wrote:
>>>> Author: efriedma
>>>> Date: Fri Dec  2 18:54:26 2011
>>>> New Revision: 145736
>>>> 
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=145736&view=rev
>>>> Log:
>>>> Track alignment in AggValueSlot.  No functional change in this patch, but I'll be introducing uses of the specified alignment soon.
>>> 
>>> Thanks!  Please make it take and vend the alignment as a CharUnits, though.
>> 
>> Actually, I'm starting to rethink this... would it make sense to
>> always ensure that an AggValueSlot is always appropriately aligned?
> 
> Hmm... thinking about it a bit more, it really isn't that much work to
> allow under-aligned AggValueSlots.  I'm wondering about RValue,
> though... it feels like we could go either way on that: either say
> they can be completely represented by a single llvm::Value*, or allow
> essentially a complete LValue to be represented by one. I'm sort of
> leaning towards the "complete LValue" approach, but it does make using
> RValue a bit more complicated.

I don't understand what you mean by "complete" here.

I'm not sure we can ever get an under-aligned RValue in a case where
it matters.  When would the generation of an r-value sua sponte result
in an under-aligned value?  If we're generating the temporary ourselves,
we can over-align it for spite and convenience.  If we're emitting into
an under-aligned destination, the alignment should be passed through
the AggValueSlot and the value in the RValue is generally ignored.

Maybe we should just take the aggregate-address option out of RValue
completely and always require a valid AggValueSlot when emitting an
aggregate r-value.  I can't think of anything that would lose us;  maybe
some optimizations that we could just as easily make happen in
EmitIgnoredExpr.

John.