search for: transformzexticmp

...pairs could then (possibly) be optimized by another optimization (which has already been there before r48715), to replace them by bitwise or integer operations. The code in question is located in `visitZExt()` in InstCombineCasts.cpp: ``` if (ICmpInst *ICI = dyn_cast<ICmpInst>(Src)) return transformZExtICmp(ICI, CI); BinaryOperator *SrcI = dyn_cast<BinaryOperator>(Src); if (SrcI && SrcI->getOpcode() == Instruction::Or) { // zext (or icmp, icmp) --> or (zext icmp), (zext icmp) if at least one // of the (zext icmp) will be transformed. ICmpInst *LHS = dyn_cast<ICmpInst>(...

...nv4 %tobool = icmp ne i32 %and5, 0 %lnot = xor i1 %tobool, true %lnot.ext = zext i1 %lnot to i32 %conv6 = trunc i32 %lnot.ext to i8 ret i8 %conv6 } ``` For both functions, the `icmp` operations will be immediately followed by `zext` instructions, which will directly be optimized away by `transformZExtICmp()`, which is the reason why in the end we will only have one of the `icmp` instructions left. However, that means that `foo` will not be lowered to the IR that we have in zext-or-icmp.ll, where the `zext` is placed after the `or` instruction as opposed to `@foo_before_InstCombine`: ``` define i8 @...

...; %lnot = xor i1 %tobool, true > %lnot.ext = zext i1 %lnot to i32 > %conv6 = trunc i32 %lnot.ext to i8 > ret i8 %conv6 > } > ``` > > For both functions, the `icmp` operations will be immediately followed by `zext` instructions, which will directly be optimized away by `transformZExtICmp()`, which is the reason why in the end we will only have one of the `icmp` instructions left. However, that means that `foo` will not be lowered to the IR that we have in zext-or-icmp.ll, where the `zext` is placed after the `or` instruction as opposed to `@foo_before_InstCombine`: > > ``` &...

...nd I kind of dislike that option too, which is why I am > trying to openly expose my reasons for that. > > As per your question, the following are the ‘undesirable' InstCombine > transforms that I identified: > > int testSimplifySetCC_0( int x ) // 904 > (InstCombineCasts::transformZExtICmp) > { > return (x & 32) != 0; > } > > define i16 @testSimplifySetCC_0(i16 %x) { > entry: > %and = lshr i16 %x, 5 > %and.lobit = and i16 %and, 1 > ret i16 %and.lobit > } > > > int testSExtICmp_0( int x ) // 1274 (InstCombineCasts:transformSExtICmp)...

As before, I'm not convinced that we want to allow target-based enable/disable in instcombine for performance. That undermines having a target-independent canonical form in the 1st place. It's not clear to me what the remaining motivating cases look like. If you could post those here or as bugs, I think you'd have a better chance of finding an answer. Let's take a minimal example

For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp ~Craig On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > > int cmpge32_0(long a) { > return a>=0; > } > > Comp...

...mpact of each target-independent transform on every target. > > > On Mon, Sep 30, 2019 at 5:31 PM Craig Topper <craig.topper at gmail.com <mailto:craig.topper at gmail.com>> wrote: > For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp > > ~Craig > > > On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com <mailto:support at sweetwilliamsl.com>> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > &...

...rget-independent transform on every target. >> >> >> On Mon, Sep 30, 2019 at 5:31 PM Craig Topper <craig.topper at gmail.com <mailto:craig.topper at gmail.com>> wrote: >> For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp >> >> ~Craig >> >> >> On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com <mailto:support at sweetwilliamsl.com>> wrote: >> Hi all, >> >> Ok, I just found a much simpler example of the same issue. >> >...

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt