llvm dev - Apr 2020 - Branch is not optimized because of right shift

> On Apr 5, 2020, at 22:20, Stefanos Baziotis <stefanos.baziotis at
gmail.com> wrote:
> 
> > Any idea about how the compiler could remove the lshr and use a add
-16?
> Actually, I just figured that doing this test is like solving this:
> 
> 8 <= x/2 <= 13
> 16 <= x <= 26
> 0 <= x - 16 <= 10 => 0 <= x < 11
> The left part is know since it's unsigned
> The right part could be done x <= 11 => x < 12 because it's
actually an integer division.
> Wow... I would be really happy to know what pass does that.
I’d guess a combination of instcombine rules together with some other
transforms. You could probably use `-print-after-all` (`clang -mllvm
-print-after-all` if you are using clang) to track down the relevant
passes/steps.

Thanks, I didn't know that! Indeed, it's instruction combine that does
the
job.

- Stefanos

Στις Δευ, 6 Απρ 2020 στις 12:38 π.μ., ο/η Florian Hahn <
florian_hahn at apple.com> έγραψε:
>
>
> > On Apr 5, 2020, at 22:20, Stefanos Baziotis <stefanos.baziotis at
gmail.com>
> wrote:
> >
> > > Any idea about how the compiler could remove the lshr and use a
add
> -16?
> > Actually, I just figured that doing this test is like solving this:
> >
> > 8 <= x/2 <= 13
> > 16 <= x <= 26
> > 0 <= x - 16 <= 10 => 0 <= x < 11
> > The left part is know since it's unsigned
> > The right part could be done x <= 11 => x < 12 because
it's actually an
> integer division.
> > Wow... I would be really happy to know what pass does that.
>
> I’d guess a combination of instcombine rules together with some other
> transforms. You could probably use `-print-after-all` (`clang -mllvm
> -print-after-all` if you are using clang) to track down the relevant
> passes/steps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200406/6b5a7e7e/attachment.html>

Adding a nuw to the add -8 is incorrect. From the perspective of the
unsigned math, -8 is treated a very large positive number. The input to the
add is [8,13) and adding a large positive number to it wraps around past 0.
So that is guaranteed unsigned wrap. On the other hand, a sub nuw 8 would
be correct.

~Craig


On Sun, Apr 5, 2020 at 3:27 PM Stefanos Baziotis via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thanks, I didn't know that! Indeed, it's instruction combine that
does the
> job.
>
> - Stefanos
>
> Στις Δευ, 6 Απρ 2020 στις 12:38 π.μ., ο/η Florian Hahn <
> florian_hahn at apple.com> έγραψε:
>
>>
>>
>> > On Apr 5, 2020, at 22:20, Stefanos Baziotis <
>> stefanos.baziotis at gmail.com> wrote:
>> >
>> > > Any idea about how the compiler could remove the lshr and use
a add
>> -16?
>> > Actually, I just figured that doing this test is like solving
this:
>> >
>> > 8 <= x/2 <= 13
>> > 16 <= x <= 26
>> > 0 <= x - 16 <= 10 => 0 <= x < 11
>> > The left part is know since it's unsigned
>> > The right part could be done x <= 11 => x < 12 because
it's actually an
>> integer division.
>> > Wow... I would be really happy to know what pass does that.
>>
>> I’d guess a combination of instcombine rules together with some other
>> transforms. You could probably use `-print-after-all` (`clang -mllvm
>> -print-after-all` if you are using clang) to track down the relevant
>> passes/steps.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200405/6ee4de3d/attachment.html>