search for: zextload

...ted by armv2a, so I need to make the code generation to not generate ldrh instructions. I want to replace all those instances with a 32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to accomplish that: 1. Register the ZEXTLOAD for custom lowering: setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Custom); 2. Implement a custom lowering function: static SDValue LowerExtLoad(SDValue Op, SelectionDAG &DAG) { LoadSDNode *LD = dyn_cast<LoadSDNode>(Op.getNode()); ISD::LoadExtType ExtType = LD->getExtensionType();...

...at makes sense. The issue we are having is this: we don't support 8 bit loads and we don't support 8 bit extloads, so we end up with LD1 with zext after either the first pass or the second pass (depending on the test case). If we add the TargetLowering callback method setLoadExtAction(ISD::ZEXTLOAD, MVT::i8, Expand) then it crashes during legalization and if we don't have that in then it crashes during instruction selection. There are two ways to fix this: 1) Add the setLoadExtAction AND comment out 'LegalOperations &&' in the conditional. (this solves the problem) 2) C...

...t) places. That makes sense to me, but note that this is not currently implemented. All our RISC-like targets only support folding of COPY to load/store through the target-independent mechanisms. It should be fairly simple to add a foldMemoryOperandImpl override to ARM that folds load+zext into a zextload. /jakob

...; 0x229d8d0, 0x229d9d0<LD4[FixedStack-1](align=8), zext from i32> > [ID=14] > 0x229d8d0: i64 = FrameIndex<-1> [ORD=1] [ID=3] > 0x229d9d0: i64 = undef [ORD=1] [ID=4] [Villmow, Micah] This is a zero extending load and not just a normal load. Do you handle the pattern fragment zextload in your tablegen? You can try to do setLoadExtAction(ISD::ZEXTLOAD, MVT::i64, Expand); in your ISelLowering constructor if you don't support this natively. > > What exactly does this mean? OK, it means that some load instruction > could not be selected. But why? Is the instruction no...

...igned loads. I had to custom lower i8 load so that only i32 loads are generated. My issue is the following: In a very specific case, the lowering stage generates the following pattern where the load is a i32 load: (and (load x), 255) This pattern is somehow converted by the DAG combiner back to: (zextload x, i8) And then, during the instruction selection phase, I get: error in backend: Cannot select: 0xb3a5558: i32,ch = load 0xb3823c4, 0xb3a1890, 0xb3a2440<LD1[%4](align=4), zext from i8> because the instruction is simply not supported by the backend (that's the initial reason for implement...

...lt;8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0 pand <0xff,0xff,...>, %xmm0, %xmm0 v8i8 isn't legal, so the load became an anyext load from v8i8 to v8i16, with the pand masking out the unwanted/zero bits. In that example, if you declare zextloads from v8i8 legal, and add the simple corresponding pattern, the pand isn't generated anymore, as expected. So, unless I'm missing something, shouldn't we declare them legal? Insights much appreciated, thanks! - Ahmed

...aving is this: we don't support 8 bit loads and we > don't > > support 8 bit extloads, so we end up with LD1 with zext after either the > > first pass or the second pass (depending on the test case). If we add the > > TargetLowering callback method setLoadExtAction(ISD::ZEXTLOAD, MVT::i8, > > Expand) then it crashes during legalization > > This part is surprising. What happens? This seems to me like the > correct solution. > > I'm guessing it's because there's no good way to legalize 8 bit loads? > I have no idea what happens when tho...

...9d9d0<LD4[FixedStack-1](align=8), zext from i32> >> [ID=14] >> 0x229d8d0: i64 = FrameIndex<-1> [ORD=1] [ID=3] >> 0x229d9d0: i64 = undef [ORD=1] [ID=4] > [Villmow, Micah] This is a zero extending load and not just a normal load. Do you handle the pattern fragment zextload in your tablegen? > You can try to do setLoadExtAction(ISD::ZEXTLOAD, MVT::i64, Expand); in your ISelLowering constructor if you don't support this natively. > This really brought me forward as I just missed setLoadExtAction & Co up to now, I just was aware of setOperationAction. &g...

...17f7470: i32 = srl 0x17f7070, 0x17f94c0 With ---- 0x17fceb0: i32,ch = load 0x17faa00, 0x17fac00, 0x17f6a70<LD2[%arrayidx4+2], zext from i16> That seems like a logical thing to do on a lot of targets, but in my case, the LD4->SRL combo was emitted precisely because I *don't* want a ZEXTLOAD i16. I'm wondering if there is: a) A way to turn off this optimization in DAGCombine if your target doesn't support LD2 natively b) A way to (repeatedly) call my LowerLOAD/LowerSTORE functions after DAGCombine until no LD1's or LD2's remain c) A completely different way I should...

...; That makes sense to me, but note that this is not currently implemented. All our RISC-like targets only support folding of COPY to load/store through the target-independent mechanisms. > > It should be fairly simple to add a foldMemoryOperandImpl override to ARM that folds load+zext into a zextload. Really? I'm pretty sure that ppc folded load into [sz]ext (with custom code). If ARM isn't doing this, it should - it is a clear win. -Chris

...k it should be a goal of the new framework to make this a bit easier. +1 Do you and/or Adrian also have thought on testing debug values? Verification and testing strategies should/could be part of the design also. > > best, > vedant > > [1] To pick one at random, the '(zext (zextload x)) -> (zext (truncate (zextload x)))' combine should transfer debug values from N to the new ExtLoad, and from N0 to the new (trunc ExtLoad), but currently doesn't. > >> >> Thanks, >> Amara >> _______________________________________________ >> LLVM Dev...

...i8 load so that only i32 loads are generated. > > My issue is the following: > In a very specific case, the lowering stage generates the following pattern > where the load is a i32 load: > (and (load x), 255) > This pattern is somehow converted by the DAG combiner back to: >  (zextload x, i8) > And then, during the instruction selection phase, I get: > error in backend: Cannot select: 0xb3a5558: i32,ch = load 0xb3823c4, > 0xb3a1890, 0xb3a2440<LD1[%4](align=4), zext from i8> > because the instruction is simply not supported by the backend (that's the > ini...

...akes sense to me, but note that this is not currently implemented. All our RISC-like targets only support folding of COPY to load/store through the target-independent mechanisms. >> >> It should be fairly simple to add a foldMemoryOperandImpl override to ARM that folds load+zext into a zextload. > > Really? I'm pretty sure that ppc folded load into [sz]ext (with custom code). If ARM isn't doing this, it should - it is a clear win. It is entirely possible I broke it when I added the COPY instruction. I deleted the RISC target hooks for foldMemoryOperandImpl, thinking tha...

...s only allowed to produce legal > operations, and bails out if it would create an illegal extending load. > However the later logic in ReduceLoadWidth doesn't do any such checking > as far as I can see, which is wrong. > > It does appear the same test should be applied to the ZEXTLOAD case too. For my case where I do custom lowerings TLI.isLoadExtLegal() considers custom lowerings as being legal Should these tests exclude custom lowerings? TLI.isLoadExtLegal() is not declared as being virtual - should it be? If I override TLI.isLoadExtLegal() and exclude custom lowerings i...

Hi LLVM-Folks, as mentioned in an earlier post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I am currently working on a Back-End for the TriCore processor. Currently, I am struggling as LLVM could not select zext and load, for instance, so some of the testcases in test/CodeGen/Generic are not successfully compiled by my back-end. Furthermore, I am completely puzzled by the

...ed at other targets to see what they do but can't see what I am missing. > > Help please! > Thank you > > Robert The instruction selector only operates within a block. An IR CodeGenPrepare pass runs first and attempts to hoist the zext into the load’s block if it sees a legal zextload pattern (isLoadExtLegal). I’m not sure why the zero_extend isn’t hoisted in your case. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/91fc2903/attachment.html>

...> > With > ---- > 0x17fceb0: i32,ch = load 0x17faa00, 0x17fac00, > 0x17f6a70<LD2[%arrayidx4+2], zext from i16> > > That seems like a logical thing to do on a lot of targets, but in my > case, the LD4->SRL combo was emitted precisely because I *don't* want a > ZEXTLOAD i16.  I'm wondering if there is: > > a) A way to turn off this optimization in DAGCombine if your target > doesn't support LD2 natively This. I think you're talking about DAGCombiner::ReduceLoadWidth... and the "if (LegalOperations && !TLI.isLoadExtLegal(ExtType,...

.... > > --- > > Adrian and others have thought about these issues much more, so take these ideas with a grain of salt :). > > thanks, > vedant > > >>> >>> best, >>> vedant >>> >>> [1] To pick one at random, the '(zext (zextload x)) -> (zext (truncate (zextload x)))' combine should transfer debug values from N to the new ExtLoad, and from N0 to the new (trunc ExtLoad), but currently doesn't. >>> >>>> >>>> Thanks, >>>> Amara >>>> _________________________...

...>> 0x17fceb0: i32,ch = load 0x17faa00, 0x17fac00, >> 0x17f6a70<LD2[%arrayidx4+2], zext from i16> >> >> That seems like a logical thing to do on a lot of targets, but in my >> case, the LD4->SRL combo was emitted precisely because I *don't* want a >> ZEXTLOAD i16. I'm wondering if there is: >> >> a) A way to turn off this optimization in DAGCombine if your target >> doesn't support LD2 natively > > This. > > I think you're talking about DAGCombiner::ReduceLoadWidth... and the > "if (LegalOperations&...

...](align=8), zext from i32> > >> [ID=14] > >> 0x229d8d0: i64 = FrameIndex<-1> [ORD=1] [ID=3] > >> 0x229d9d0: i64 = undef [ORD=1] [ID=4] > > [Villmow, Micah] This is a zero extending load and not just a normal > load. Do you handle the pattern fragment zextload in your tablegen? > > You can try to do setLoadExtAction(ISD::ZEXTLOAD, MVT::i64, Expand); > in your ISelLowering constructor if you don't support this natively. > > > > This really brought me forward as I just missed setLoadExtAction & Co up > to now, I just was aw...