llvm dev - Apr 2015 - [LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?

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?

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

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>

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>

On 04/20/2015 01:25 PM, David Majnemer wrote:
> These optimizations are not always run on IR that is fed to the backend.
The DAG combiner also performs the undefined shift -> undef though, so 
it should still be OK

-Matt