PATCH + test for PR18032 (InstCombine issue)

Stepan Dyatkovskiy stpworld at narod.ru
Mon Dec 23 07:04:35 PST 2013


Hi Ben,

 > Why do you think this is an issue? The alignment of a NULL point is 
essentially
 > infinite, picking the largest possible value is odd but it shouldn't 
cause problems.

May be its not a bug. And obviously it is not. Though it is still not 
quite expected behaviour. If it's not a bug, can we close PR18032 issue 
then?

-Stepan.

Benjamin Kramer wrote:
>
> On 20.12.2013, at 12:45, Stepan Dyatkovskiy <stpworld at narod.ru> wrote:
>
>> Hi all,
>> Please find in attachment my PR18032 fix for review.
>>
>> Issue description:
>> InstCombine Pass emits wrong alignment for 'load' instruction with 'null' as
>> address.
>> Problem was in Local.cpp, llvm::getOrEnforceKnownAlignment method.
>> Method analyzes trailing zeroes in address values and suggest its own
>> aligment.
>> For example: for address 0x123123a8 we have 3 binary trailing zeroes, and
>> thus, method will suggest you 8 bytes alignment.
>> Doing same logic, it will suggest you maximum possible alignment (2^29) for
>> 'null' pointer.
>> Then InstCombiner::visitLoadInst method will select maximum alignment of what
>> was given in IR and what was suggested by getOrEnforceKnownAlignment; these
>> strings:
>>    if (KnownAlign > EffectiveLoadAlign)
>>      LI.setAlignment(KnownAlign);
>> So, finally we got align of 536870912 bytes:
>
> Why do you think this is an issue? The alignment of a NULL point is essentially
> infinite, picking the largest possible value is odd but it shouldn't cause problems.
> Special casing NULL doesn't make sense to me either, you'll still get a ridiculously
> large alignment value e.g. for a constant 0x80000000 pointer.
>
> When I compile the test case from PR18032 with clang/LLVM trunk I get
>
> 	movq	%gs:0, %rax
> 	movq	8(%rax), %rsi
>
> which looks right to me, maybe it was an issue in 3.3 that has been fixed already?
>
> - Ben
>
>>
>> The fix:
>> Add one more special case for getOrEnforceKnownAlignment. If address is 0,
>> we don't need to anylize trailing zeroes,
>> just return alignment known already (PrefAlign value).
>>
>> -Stepan
>> <pr18032-2013-12-20.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list