[llvm-commits] [llvm] r61934 - in /llvm/trunk: lib/Analysis/ValueTracking.cpp test/Transforms/InstCombine/2009-01-08-AlignAlloca.ll

Dan Gohman gohman at apple.com
Thu Jan 8 16:14:23 PST 2009


On Jan 8, 2009, at 2:49 PM, Chris Lattner wrote:

>
> On Jan 8, 2009, at 2:25 PM, Dan Gohman wrote:
>
>>
>> On Jan 8, 2009, at 12:48 PM, Chris Lattner wrote:
>>
>>> On Jan 8, 2009, at 11:45 AM, Dan Gohman wrote:
>>>>> it will just get the ABI alignment.  This prevents instcombine  
>>>>> from
>>>>> rounding
>>>>> up the alignment of a load/store without adjusting the alignment  
>>>>> of
>>>>> the alloca.
>>>>
>>>> When would a default-alignment Alloca not be given its preferred
>>>> alignment?
>>>>
>>>> Or, if you prefer that instcombine make give all Allocas an  
>>>> explicit
>>>> alignment, could you add a comment to this code?
>>>
>>> InstCombine already has code to handle this (see
>>> EnforceKnownAlignment).  It isn't catching this case, but it could  
>>> be
>>> made to do so if it were important.
>>
>> Perhaps I was unclear. Is this commit fixing a miscompile?  If so,
>> it seems that there's a bug elsewhere.  CodeGen ought to be aligning
>> such Allocas at their preferred alignment.
>
> No, this is just something that Evan noticed.  I don't know that it
> actually manifested as a bug.


This is actually a pretty significant language change.  With this
commit, if front-ends want loads and stores from allocas to be done
with preferred alignment, they have to add all the alignment
directives manually. Previously, this just happened automatically.

I think the previous behavior is more useful. It doesn't make a
lot of sense to pretend that the allocas might not be allocated
according to preferred alignment when they always are.

It looks like LangRef.html is a little ambiguous in this area; I
suggest this wording in the description of the alignment value in
the alloca instruction documentation:

"If not specified, or if zero, the target will align the allocation
according to the preferred alignment for the allocated object's type."

Dan




More information about the llvm-commits mailing list