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

[Ryan Taylor]

As in O0, I see.

Thanks.

On Mon, Apr 20, 2015 at 4:25 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

>
>
> 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/04c07113/attachment.html>