[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 3, 2011, at 1:15 AM, Eli Friedman wrote:
> 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.

Hmm.  There's enough complexity in call arguments that they could
stand to have their own dedicated representation.  For now, though,
I guess adding an alignment to RValue is fine.

John.