search for: zero_extend

At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND gives me the new chain LOAD -> ANY_EXTEND -> AND. I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). Combine(AfterLegalizeTypes) is no called at all. - Elena -----Original Message----- From: Eli Fr...

...ation(SDValue(N, 0), DAG); for (unsigned I = 0, E = Res->getNumValues(); I != E; ++I) Results.push_back(Res.getValue(I)); I did have to put in the following as well: SDValue LHS = Op.getOperand(0); SDValue RHS = Op.getOperand(1); LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS); RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS); return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MVT::i64, LHS, RHS); In order to get the operation to be able to be able to go forward and match the new operation with the input operands (w...

...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 this indicates t...

On Tue, Feb 7, 2012 at 12:38 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. > After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND  gives me the new chain LOAD -> ANY_EXTEND -> AND. > > I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). That sounds like it's just a matter of making sure we don't forget to add the...

...or spilt accordingly. Floating point and boolean vector MVTs are the exception whereby the smaller than usually legal types are legal and considered to contain unpacked data within a larger container. The type legalisation of: nxv2i8 ADD(nxv2i8, nxv2i8) results in: nxv2i8 TRUNC(nxv2i64 ADD((ZERO_EXTEND MVT::nxv2i8), (ZERO_EXTEND MVT::nxv2i8))) Much of the legalisation code is common to all targets and by introducing scalable vector MVTs they also apply to SVE as long as the "scalable" flag is preserved when transforming MVTs. To achieve this we want to popularise the use of functions...

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConstant(DiffBits, TLI.getShiftAmountTy())); Results.push_back(Tmp1); break; } Notice the first DAG.getNode() call. It's using "Tmp1&...

Hi All, I have faced a problem with TargetLowering::SimplifyDemandedBits with AND. Here is a example as following: /* C source code */ struct A { unsigned int a; unsigned char c1, c2; bool b1 : 1; bool b2 : 1; bool b3 : 1; }; int main () { struct A x[1]; x[0].b1 = false; int s = 0; s = x[0].b1 ? 1 : 0; <--- Here is problem. if (s != 0) __builtin_abort

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 sign_extend an 8-...

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

...e 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>

....i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction selection: SelectionDAG has 15 nodes:   t0: ch = EntryToken                 t2: i32,ch = CopyFromReg t0, Register:i32 %0               t10: i32 = and t2, Constant:i32<65535>             t16: i64 = zero_extend t10           t17: i64 = ctlz t16         t22: i64 = add t17, Constant:i64<-32>       t20: i32 = truncate t22     t15: i32 = add t20, Constant:i32<-16>   t7: ch,glue = CopyToReg t0, Register:i32 $r2l, t15   t8: ch = SystemZISD::RET_FLAG t7, Register:i32 $r2l, t7:1 It seems that S...

On Dec 22, 2009, at 2:38 PMPST, Bill Wendling wrote: > The LegalizeDAG.cpp file has this code in > SelectionDAGLegalize::PromoteNode: > > case ISD::BSWAP: { > unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); > Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, > DAG.getConstant(DiffBits, > TLI.getShiftAmountTy())); > Results.push_back(Tmp1); > break; > } > > Notice the first DAG.ge...

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 > that either a si...

> This patch looks good, but you need to add a test case. You can add it > to the file test/CodeGen/R600/zero_extend.ll Version 2 of patch attached which includes test case. -Jon -------------- next part --------------

Hi Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a

Hi, When trying to compile a trivial opencl kernel such as: __kernel void if_eq(__global int * out, int arg0, int arg1){ out[0] = arg0==arg1?0:1; } Clang generates IR like: %1 = icmp eq i32 %arg0, %arg1 %. = zext i1 %1 to i32 This eventually crashes ISel on R600. Attached patch adds a selector so it will compile. Regards, Jon Pry jonpry at gmail.com -------------- next

...k the > answer is 'yes'. We probably should add that fold. This seems like a > similar case as the recent: https://reviews.llvm.org/D48466 > > Note that on x86, the sext+add becomes zext+sub: > t20: i8 = setcc t3, Constant:i16<-1>, setgt:ch > t24: i16 = zero_extend t20 > t17: i16 = sub Constant:i16<5>, t24 > > Would that transform help your target? > > On Tue, Jul 3, 2018 at 3:55 PM, Yuan Lin <yualin at google.com> wrote: > >> Hi, Roman and Sanjay, >> >> Thank you for your reply! We currently do run DAGCo...

On Mon, Feb 6, 2012 at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. > I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change

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 t...