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

[Eli Friedman]

On Sat, Dec 3, 2011 at 12:40 AM, John McCall <rjmccall at apple.com> wrote:
> 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.

We currently stuff a potentially unaligned LValue directly into RValue
in a few places; the ones that would be tricky to fix without
introducing extra memcpy's are in CGCall.

> 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.

That's a possibility... we do need some sort of representation for
arguments to calls, though, and I can't imagine any representation
that doesn't look like RValue.

-Eli