similar to: [LLVMdev] global type legalization?

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: >> I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. > > That's true, but doing isel as a purely local approach

On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: > I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. That's true, but doing isel as a purely local approach isn't the best either :-). We'd really like to get to

On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. >

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

On Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > > On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > >> >> 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*

On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > > 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

Returning to an old discussion here.... On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote: > On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >>> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function

On Aug 18, 2010, at 11:31 AM, Jakob Stoklund Olesen wrote: > > On Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > >> >> On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: >> >>> >>> 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

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 can be difficult for zexts. define

Dear there, I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. My initial thought is: (1) I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not

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 just say that code has undefined

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

I'm looking at the output of memcmp() expansion (D34904), and I noticed that there are many ways to produce the common positive/zero/negative comparison result in IR. For the following 6 functionally equivalent C source functions, we produce 6 different versions of IR which leads to 6 different asm outputs for x86. Which of these should we choose as canonical IR form? 1. Two selects int

I have another round of questions about IR select canonicalizations. 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

Hi Sanjay, On 19 Jul 2016, at 18:54, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: Hi Artur - I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in https://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern. It's probably worth noting that I'm

Hi Chandler, all, Why aren't the vector [zs]extloads introduced by SSE4.1/AVX2 declared legal? Is it a simple oversight, or did I miss a deeper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0

In my language there are a lot of i16 definitions, but almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases

John McCall wrote: > I didn't realize that an identity zext was actually invalid IR. That > seems like it probably causes more trouble than it's worth. > > Anyway, I suspect the question is whether you would rather break these > invariants (which are probably not critical for most optimizations) or > slowly accumulate duplicate code paths in every pass that looks at

Chris Lattner wrote: > 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. >>

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 with two incoming i8 values, both resulting from `zext i1