search for: zext

...but please correct me in case I'm thinking in the wrong direction. > Am 21.07.2016 um 18:51 schrieb Sanjay Patel <spatel at rotateright.com>: > > I've been fixing similar problems recently (eg, https://llvm.org/bugs/show_bug.cgi?id=28476 ). I think your example (the test in zext-or-icmp.ll) is another missed application of DeMorgan's Law: > > char foo(char a, char b) { > return (((a & 1) == 0) | (b == 0)); > } > > char goo(char a, char b) { > return !(((a & 1) != 0) & (b != 0)); > } > > Make sure I didn't botch that...

Hi all, I have a question regarding a transformation that is carried out in InstCombine, which has been introduced by r48715. It unfolds expressions of the form `zext(or(icmp, (icmp)))` to `or(zext(icmp), zext(icmp)))` to expose pairs of `zext(icmp)`. In a subsequent iteration these `zext(icmp)` 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...

...Am 02.08.2016 um 21:39 schrieb Sanjay Patel <spatel at rotateright.com>: > > Hi Matthias - > > Sorry for the delayed reply. I think you're on the right path with D22864. No problem, thank you for your answer! > If I'm understanding it correctly, my foo() example and zext_or_icmp_icmp() will be equivalent after your patch is added to InstCombine. Yes, that’s correct. > If that's right, then you will be able to add a pattern match in matchDeMorgansLaws() for that exact sequence of instructions where we only have one icmp that is zexted. As you noted, we can&...

...avior. > > > > The problem is not that we're losing information, the problem is that > we're changing the behavior of a well-defined program. > > I'll try to put the whole argument in one place: > > We start with > > %x = add nuw i32 %m, %n > %y = zext i32 %x to i64 > %s = lshr i64 %y, 32 > %addr = gep %some_global, %s > store i32 42, i32* %addr > > In the above program, for all values of %x, %s is 0. This means the > program is well-defined when %x is poison (since you don't need to > look at %x to determine the v...

My gut tells me that Hal is right, and we should prefer zexts as long as the select boils down to one instruction, but let me go against my intuition and try to list two reasons why we should prefer selects: * Folding operations into selects: it is trivial to transform f(select X, Const0, Const1) to select X, f(Const0), f(Const1), while doing that...

...but it seems to me that you can do lots of sensible things, and avoid lots of silly things, if you keep track of four possible values for each bit: - undef (the default) - poison - known to be 0 - known to be 1 This makes both David's and Chandler's examples work nicely if you assume: - ZEXT makes all the new bits known 0 - SEXT makes all the new bits the same as the high bit - AND clears unknown and poison bits to known 0 if the other input is known 0 - OR sets unknown and poison bits to known 1 if the other input is known 1 Also things such as ZEXTing a poison i32 to i64 and then ri...

..., that I'm missing > something. The problem is not about how to codegen a specific SCEV expression efficiently, but about the overall solution LSR converges to (which includes considering how it will codegen *other* SCEVs). In the latter sense there is a difference between `X` and `(trunc (zext X))` even though both of them produce the same value (and possibly are equally efficient). The example in [1] is roughly like this at the high level: You have an i32 induction variable `V` == `{VStart,+,1}`. `{VStart,+,1}` does not unsigned-overflow given the loop bounds. Two interesting uses in...

...onicalizations. For the purity of this quiz, please disregard prior knowledge of how this is handled by instcombine or how this is lowered by your favorite target...of course we'll fix it. :) Some answers in the links below if you do want to know. Which, if any, of these is canonical? 1. Is a zext simpler than a select? a. define i32 @sel_1_or_0(i1 %a) { %b = select i1 %a, i32 1, i32 0 ret i32 %b } b. define i32 @sel_1_or_0(i1 %a) { %b = zext i1 %a to i32 ret i32 %b } 2. What if we have to 'not' the bool? a. define i32 @sel_0_or_1(i1 %a) { %b = select i1 %a, i32 0, i32 1...

On Tue, Jan 27, 2015 at 8:32 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Correct me if I am wrong but we are talking about transforming: > > %maybe_poison = add nuw i32 %a, %b > > %x = zext i32 %maybe_poison to i64 > > %y = lshr i64 %x 32 > > > > To: > > %za = zext i32 %a to i64 > > %zb = zext i32 %b to i64 > > %x = add nuw i64 %za, %zb > > %y = lshr i64 %x 32 > > > > ? > > > > If so, this seems fine in t...

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't* folded into a load, what you're really looking for is a code placement pass which tries to put the zexts in non-redundant (and non-partially redundant) places. That makes...

On Tue, Jan 27, 2015 at 7:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi David, > > I spent some time thinking about poison semantics this way, but here > is where I always get stuck: > > Consider the IR fragment > > %x = zext i32 %maybe_poison to i64 > %y = lshr i64 %x 32 > %ptr = gep %global, %y > store 42 to %ptr > > If %maybe_poison is poison, then is %y poison? For all i32 values of > %maybe_poison, %y is i64 0, so in some sense you can determine the > value %y without looking at %x. I...

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext...

> Of course, and the point is that, for example, on x86_64, the zext here is free. I'm still trying to understand the problem... > > In the example you provided in your previous e-mail, we choose the solution: > > `GEP @Global, zext(V)` -> `GEP (@Global + zext VStart), {i64 0,+,1}` > `V` -> `trunc({i64 0,+,1}) + VStart` > > instead...

> To back up for a second, how much of this is self-inflicted damage? > IndVarSimplify likes to preemptively widen induction variables. Is > that why you have the extensions here in the first place? In the specific example I was talking about the zext came from our frontend (our FE used to insert these extensions for reasons that are no longer relevant). But you can easily get the same behavior from an expression like `a[(unsigned long)i]`. This looked like a fairly straightforward LSR problem to me, especially because SCEV already has all the...

...pointers.com> > > wrote: > >> > >> Hi David, > >> > >> I spent some time thinking about poison semantics this way, but here > >> is where I always get stuck: > >> > >> Consider the IR fragment > >> > >> %x = zext i32 %maybe_poison to i64 > >> %y = lshr i64 %x 32 > >> %ptr = gep %global, %y > >> store 42 to %ptr > >> > >> If %maybe_poison is poison, then is %y poison? For all i32 values of > >> %maybe_poison, %y is i64 0, so in some sense you can d...

Hi, AFAICT there are two places where zext instructions may get folded into PHI nodes. One is FoldPHIArgZextsIntoPHI and the other is the more generic FoldPHIArgOpIntoPHI. Now, the former only handles PHIs with more than 2 incoming values, while the latter only handles casts where the source type is legal. This means that for an PHI node w...

Hi Mehdi, On Wed, Oct 19, 2016 at 8:29 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> sext(x): >> t = zext x >> result = 0 >> for i = 0 to bitwidth: >> result |= t << i; >> return result > > I don’t understand this definition of sext? > Are you trying to express that we will copy the sign one bit at a time, and so every `new` bit is a new “read” of the undef...

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a pessimistic value for it. We don't get the more precise answer the second time because we bail out on proving the...

...previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This can manifest in multiple ways: - We cannot get the back-edges taken count since SCEV because we may have something like (sext (1,+1)) which we can't evaluate as it can overflow - We cannot get SCEV AddRec expressi...

On Nov 12, 2009, at 11:29 PM, John McCall wrote: >> sext/zext/trunc are very nice for the optimizer, we should keep >> them. It means that the optimizer doesn't have to check that the >> input to a sext is bigger or smaller than the result, for example. >> Code that cares (e.g. instcombine) really likes this. > > We could j...