search for: setloadextact

...independent yes? So that 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 t...

...CC, ISD::CopyToReg, ISD::AssertSext) 2. The MVT::glue value is used to ensure two nodes are scheduled together and in order. In the other word, we can’t insert any instruction of them in the scheduling, is it correct? 3. In the ARMISelLowering constructor, it sets the callback function with setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote); My question is ARM don’t support MVT::i1 registerclass, why should it determine this operation with MVT::i1 value? Can anyone tell me? Thank you very much. Best regards, Zakk -------------- next part -------------- An HTML attachment was scrubbed... UR...

...ttp://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019929.html) gave me the impression that it should be possible, but maybe I misinterpreted. Below is what I've tried (on an LLVM last synced with upstream ~3 weeks ago). I've set my target to promote i16 loads in its TargetLowering. setLoadExtAction(ISD::EXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::SEXTLOAD, MVT::i16, Promote); The DataLayout is "e-p:32:32:32-i8:8:8-i16:32:32-i32:32:32-n32" If I test with a simple function as the following (which adds two i16 argu...

...gt; 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 > > 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...

...> >> [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. >> What exactly does this mean? OK, it means that s...

...d to a 32bit load For the given testcase, that's clearly illegal. Either there's a serious bug in LLVM, or you're misinterpreting the meaning of the DAG. Are you sure you aren't seeing a sign-extending load? If you don't want to bother supporting extending loads, you can use setLoadExtAction to make Legalize take care of it. > 1) I'm limited to 32bit aligned loads and llvm is assuming a > 16bit/8bit alignment You shouldn't be seeing any unaligned loads post-Legalize unless you explicitly ask for them by setting allowUnalignedMemoryAccesses to true. -Eli

...lign=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 not supported as it > is (I doubt this as there a...

...ype legalization. There is a VALUETYPE node with type MVT::Other that contains the type MVT::i1 as an auxiliary datum. My confusion is the unsupported type( like MVT::i1) have converted > to supported type in LegalizeTypes phase, > They have. but the setXXXXAction > callbacks(like setLoadExtAction(ISD::**SEXTLOAD, MVT::i1, Promote);) > Here MVT::i1 is not referring to the type of any node, it is referring to the extra data held in the VALUETYPE node argument of the SEXTLOAD node. are used to eliminate any operations that are unsupported > on the target in Legalize phase after th...

...le for an i8 load to be unaligned. > Any hints would be greatly appreciated, this is a blocking issue that I just > cannot seem to resolve without modifying the LLVM codebase to remove the > extend + load -> extload combining step. LLVM will "uncombine" it for you if you use setLoadExtAction with the appropriate arguments. -Eli

...e TriCore does not really support i64 only paired 32.bit registers, but I need such a register class as some instructions require them. So, the Legalizer thinks i64-instructions are legal and integer types above i32 are not legalized automatically. For the most operations I used setOperationAction, setLoadExtAction, ... and now I have to handle loads/stores for i33. Maybe you can guide me, where I shall look at inside LLVM how to do that. Ciao, Fabian

...e 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(); if (LD->getExtensionType() ==...

...r if I just had to take care of some special instructions on the TriCore that involve ER registers (like multiplication/division). - However, the segfault caused by the NULL-pointer returned by getRepRegClassFor() is the reason why I added this register class and used a lot of setOperationActions, setLoadExtAction, ... or lowered some thins manually. > Side note: you can autogenerate register names :) Nice, saves typing. Is there an example I can have a look at. Most targets I examined seem to do this explicitly. Ciao, Fabian

I have the following function: define void @test_fc_0_kernel(i16 signext %x, i16 signext %y, i16 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %call = tail call i32 @get_id(i32 0) ; <i32> [#uses=2] %cmp = icmp slt i16 %x, %y ; <i1> [#uses=1] br i1 %cmp, label %if.then, label %if.end

I'm still trying to track down some alignment issues with loads(i.e. 8/16 bit loads being turned into 32bit sign extending loads) and I cannot for the life of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned

Fabian, > here are the definitions of these register classes: > > // Data register class > def DR : RegisterClass<"TriCore", [i32], 32, > (add D0, D1, D2, D3, D4, D5, D6, D7, > D8, D9, D10, D11, D12, D13, D14, D15)>; > > // Extended-size data register class > def ER :

...4 only >> paired 32.bit registers, but I need such a register class as some >> instructions require them. So, the Legalizer thinks i64-instructions >> are legal and integer types above i32 are not legalized automatically. >> For the most operations I used setOperationAction, setLoadExtAction, >> ... and now I have to handle loads/stores for i33. Maybe you can guide >> me, where I shall look at inside LLVM how to do that. > > I'm not entirely sure why, but this seems to be a very frequent > mistake: don't mark i64 legal unless you actually have i64 regist...

...eally support i64 only > paired 32.bit registers, but I need such a register class as some > instructions require them. So, the Legalizer thinks i64-instructions > are legal and integer types above i32 are not legalized automatically. > For the most operations I used setOperationAction, setLoadExtAction, > ... and now I have to handle loads/stores for i33. Maybe you can guide > me, where I shall look at inside LLVM how to do that. I'm not entirely sure why, but this seems to be a very frequent mistake: don't mark i64 legal unless you actually have i64 registers. Lying to the lega...

...; >> 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. [Villmow, Micah] Yep, this is rel...

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

...gt; paired 32.bit registers, but I need such a register class as some >>> instructions require them. So, the Legalizer thinks i64-instructions >>> are legal and integer types above i32 are not legalized automatically. >>> For the most operations I used setOperationAction, setLoadExtAction, >>> ... and now I have to handle loads/stores for i33. Maybe you can guide >>> me, where I shall look at inside LLVM how to do that. >> >> I'm not entirely sure why, but this seems to be a very frequent >> mistake: don't mark i64 legal unless you actu...