search for: sign_extend

My target has only logical shifts and lacks an arithmetic right shift instruction. I have a custom LowerSRA function that rewrites SRA as SHL + SIGN_EXTEND when the shift width is either constant 16 or 24. Unfortunately, I observe that a later pass combines the SHL + SIGN_EXTEND back into SRA so we crash. The idea I had for defeating this behavior is lower to a target-specific version of SHL and/or SIGN_EXTEND, rather than using the generic ISD::SH...

Duncan Sands wrote: > Hi Greg, > >> 1) What causes the Initial selection DAG code to choose an any_extend >> over a sign_extend (or zero_extend)? > > because it is more efficient: the backend gets more choice in how to do > it, and at the same time it tells the optimizers that the extra bits > contain rubbish, which gives them more freedom to reason. Makes sense, though I was wondering why it would choose to si...

...initial selection DAG acomplishes this using an any_extend node, which isn't handled later on by any instruction selector and thus LLVM can't produce the target code. Now I could just handle an any_extend load, however if you load a 8-bit or 16-bit value the initial selection DAG uses a sign_extend (or zero_extend) node to turn it into a native 64-bit type and I would like the same behaviour for 32-bit loads. So my questions are: 1) What causes the Initial selection DAG code to choose an any_extend over a sign_extend (or zero_extend)? 2) What does any_extend actually signify? Presumably...

...in the first dag combine pass, because it never checks if it should make this combination. Since it doesn't enter the section of code I mentioned earlier, it never uncombines it. When I set it to promote, it asserts on "not yet implemented". Setting it to Expand does not expand it to sign_extend and load but to extload and sign_extend, but I don't support extload either. Please correct me if I am wrong, but I've been looking at this issue for awhile now and I cannot see where it uncombines the sextload to a load and sign_extension. My current solution is to just comment out that...

Hi, I am defining Hexagons version of ReplaceNodeResults to change the a node of the type A: i8 = INTRINSIC_WO_CHAIN ... , ... , To B: SIGN_EXTEND (A) After returning from my function, the type legalizer calss ReplaceValuesUsesWith to replace the uses of A with B. Unfortunately, it replaces the use of A in the new node B too. So the node now is B: SIGN_EXTEND(B) , which is clearly bad and the compiler crashes. In the backend, I tried to cre...

Hi Greg, >>> 1) What causes the Initial selection DAG code to choose an any_extend >>> over a sign_extend (or zero_extend)? >> >> because it is more efficient: the backend gets more choice in how to do >> it, and at the same time it tells the optimizers that the extra bits >> contain rubbish, which gives them more freedom to reason. > Makes sense, though I was wondering why i...

...base address and some arbitrary offset calculations. So for example, with this code: %switch.gep = getelementptr inbounds [15 x i8], [15 x i8]* @switch.table, i16 0, i16 %2 %switch.load = load i8, i8* %switch.gep, align 1 by instrucion selection time, the argument to 'load' is (add (sign_extend (CopyFromReg %vreg2)) (WRAPPER TargetGlobalAddress<@switch.table>)) not a WRAPPER directly.

...39;s and unpack them and shift them > based on the read address. So any i8 load has a 75% chance of being > unaligned on my hardware, Oh, okay, makes sense. > I've tried setting setLoadXAction to Custom, Legal, Expand and Promote. > Setting it to Expand does not expand it to > sign_extend and load but to extload and sign_extend, but I don't > support extload either. I suppose you could consider that a bug. That said, why is this difficult to implement? You can just treat an extload of an i8 as a load of an i8 and get correct code, no? -Eli

On Tue, 9 May 2017, Krzysztof Parzyszek wrote: > def: Pat<(ld (add (WRAPPER RC:$addr), (sign_extend RC:$offset))), > (load_instruction_rr RC:$addr, RC:$offset)>; > > Where "load_instruction" is a machine load instruction with base address and > an offset, both in registers, and RC is the corresponding register class. Can I also use something more complex than a...

Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code

Hi Greg, > 1) What causes the Initial selection DAG code to choose an any_extend > over a sign_extend (or zero_extend)? because it is more efficient: the backend gets more choice in how to do it, and at the same time it tells the optimizers that the extra bits contain rubbish, which gives them more freedom to reason. > 2) What does any_extend actually signify? Presumably this indicates >...

...ay, >> >> Thank you for your reply! We currently do run DAGCombiner, but didn't >> implement this specific transformation. I just tried turning on >> convertSelectOfCosntantsToMath() in our ISelLowering, but that doesn't >> quite work because it generated a sign_extend op from i1 to i16, which our >> backend currently doesn't support. >> >> Does the DAGCombiner already has this transformation implemented? >> >> Thanks, >> --Yuan >> >> On Tue, Jul 3, 2018 at 11:22 AM Sanjay Patel <spatel at rotateright.com&g...

...ult all operations on i8 have to be promoted to i32. default: setOperationAction(i, MVT::i8, Custom); break; // Only the following operations are legal on i8 predicates. case ISD::AND: case ISD::OR: case ISD::XOR: case ISD::SETCC: case ISD::SIGN_EXTEND: break; } } and promote all i8 to i32 in HexagonTargetLowering::LowerOperation > default. The latter will require a little hack though... > I hope this helps. Thanks again for your ideas and guidance: very much appreciated. Sebastian -- Qualcomm Innovation Center, Inc is...

...default: > setOperationAction(i, MVT::i8, Custom); > break; > > // Only the following operations are legal on i8 predicates. > case ISD::AND: > case ISD::OR: > case ISD::XOR: > case ISD::SETCC: > case ISD::SIGN_EXTEND: > break; > } > } > > and promote all i8 to i32 in HexagonTargetLowering::LowerOperation That's hard work! Why don't you call it with "Promote" instead of "Custom" and let the Legalizer do the job? Does it not work? Ivan > >&...

On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > 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

On Mar 8, 2013, at 2:29 PM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for cases where the selector is a scalar, even i...

...e signext attribute: define signext i16 @f(... The target calling convention specifies that i16's are returned in i32's. When code is generated for @f this means that you get something like: 0x2696eb8: i16,ch = ... <= the i16 value 0x2696fb0: i32 = sign_extend 0x2696eb8 <= sign extended to i32 0x26970a8: ch = ArgFlags < > 0x26971a0: ch = ret 0x2696ad8, 0x2696fb0, 0x26970a8 <= here returned Perfect! Ciao, Duncan.

...> > > > Thank, > > > > Amaury SECHET > > I was fixing creating a setcc with the wrong type for the operands for a > target with the same problem, which would then hit a selection failure > later. > > It was using getSetCCResultType on the result type of the SIGN_EXTEND > node, rather than the types being compared in the setcc. The new setcc > needs to have the right type, and then the result needs to be converted to > the type of the sign_extend. > > I think in that case, it was something like (i64 sext (setcc (i32 x) (i32 > y)). getSetCCResultT...

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

...0] PromoteIntegerOperand Op #1: 0x56059c0: f32 = fpowi 0x5602580, 0x56061c0 [ORD=162] [ID=0] Do not know how to promote this operator's operand! ------ This is coming out of DAGTypeLegalizer::ExpandIntegerResult(). I've tried adding some code to expand the integer operand (operand 1) via SIGN_EXTEND[_INREG] but keep getting other consistency errors. Another approach I tried was to set the calling convention: setLibcallCallingConv(RTLIB::POWI_F32, CallingConv::C); Which would seem to force the call to convert the i32 --> i64 just like any other call, but that did not work either Any sugge...