[llvm-dev] Branch is not optimized because of right shift
Stefanos Baziotis via llvm-dev
llvm-dev at lists.llvm.org
Sun Apr 5 18:34:05 PDT 2020
> Adding a nuw to the add -8 is incorrect.
Yeah, I didn't mean to say it was correct. It was just an observation that
with nuw the optimization was happened and I asked if someone thought it
was somehow connected.
> 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
I understand yes, but I don't think it is guaranteed. Unless I miss
something, for values in [0, 7] it won't wrap. But past that and up to (and
including in the original source code) 13, it will wrap yes.
Στις Δευ, 6 Απρ 2020 στις 3:10 π.μ., ο/η Craig Topper <
craig.topper at gmail.com> έγραψε:
> 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.
> 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
>>> > 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
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev