[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?

[David Majnemer]

On Mon, Apr 20, 2015 at 1:19 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> Ok, this makes sense.
>
> So, my follow up is then why, as in Mips, R600, etc... the bit value is
> checked in the tablegen. Seems that we should expect it to fit anyways if
> it still exists at this point?
>

These optimizations are not always run on IR that is fed to the backend.


> I'm having a hard time trying to get shl to take a PatLeaf for Imm instead
> of an ImmLeaf.
>
> On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Apr 20, 2015 at 1:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>>
>>> For example:
>>>
>>> unsigned int x, y;
>>>
>>> void foo()
>>> {
>>>      y = x >> 129;
>>> }
>>>
>>> Where int is a 16bit type, the .ll is producing only 'ret void' at O3.
>>> At O0 the .ll looks fine but then llc gets rid of it an simply returns.
>>>
>>> I'm just curious what the reasoning is for this? It isn't trying to set
>>> y to anything at all.
>>>
>>
>> The optimization is performed here:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/InstructionSimplify.cpp?revision=233938&view=markup#l1278
>>
>> What will happen is:
>>   %shr = lshr i16, %x, 129
>>   store i16 %shr, i16* @y
>>
>> will get transformed into:
>>   store i16 undef, i16* @y
>>
>> Then we will delete the store of undef using the following:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp?revision=234601&view=markup#l978
>>
>>
>>> Thanks.
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150420/d7519778/attachment.html>