search for: any_extend

...I'm building a backend for a 64-bit target based on the existing Mips 32 one and I've come up against a problem with 32-bit loads. If you load a 32-bit value into a register this needs extending to fit into a native 64-bit register. The 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...

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

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 Friedman [mailto:eli.friedman at gmail.com] Sent: Tuesday, February 07, 2012 10:15 To: Demikhovsky, Elena Cc: llvmd...

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? Presuma...

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 ANY_EXTEND to the worklist. We don't need a whole additional DAGCombine run for that. -Eli

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

...9;m new to LLVM and am having problems. One problem I found stems from code in lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: visitRet(): // If this is an integer return value, we need to promote it ourselves to // the full width of a register, since getCopyToParts and Legalize will use // ANY_EXTEND rather than sign/zero. // FIXME: C calling convention requires the return type to be promoted to // at least 32-bit. But this is not necessary for non-C calling conventions. if (MVT::isInteger(RetOp.getValueType()) && RetOp.getValueType() < MVT::i64) { MVT::ValueType T...

> // If this is an integer return value, we need to promote it ourselves to > // the full width of a register, since getCopyToParts and Legalize will use > // ANY_EXTEND rather than sign/zero. > // FIXME: C calling convention requires the return type to be promoted to > // at least 32-bit. But this is not necessary for non-C calling conventions. > if (MVT::isInteger(RetOp.getValueType()) && > RetOp.getValueType() < MVT::i64) { &gt...

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

...Yet the comment makes no mention of this. There's also of no mention of the fact that you are allowed to not place anything in Results, and what that means. Also, is there any reason not to use ReplaceNodeResults rather than introducing a new method for type legalization? > + case ISD::ANY_EXTEND: > + Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break; This is wrong if PromoteIntOp_ANY_EXTEND returned a value with no node. Likewise for all the others. Better I think to simply handle the custom case immediately and return rather than trying to share code with these other case...

...erOperation have been used for different purposes by different targets, and have been implemented differently. The former is meant to legalize illegal value types and the latter is meant to legalize operations with illegal operands. So they might need different treatments. > > + case ISD::ANY_EXTEND: > > + Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break; > > This is wrong if PromoteIntOp_ANY_EXTEND returned a value with > no node. Likewise for all the others. Better I think to simply > handle the custom case immediately and return rather than trying > to sh...

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > Well the magnitude of the task is not small. > > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > > illegal operands. So we will need to change the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue.

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 anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the

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

...erand(1)).Val; + return DAG.getNode(ISD::ROTR, VT, LHSShiftArg, RHSShiftAmt).Val; } } + + // Look for sign/zext/any-extended cases: + if ((LHSShiftAmt.getOpcode() == ISD::SIGN_EXTEND + || LHSShiftAmt.getOpcode() == ISD::ZERO_EXTEND + || LHSShiftAmt.getOpcode() == ISD::ANY_EXTEND) && + (RHSShiftAmt.getOpcode() == ISD::SIGN_EXTEND + || RHSShiftAmt.getOpcode() == ISD::ZERO_EXTEND + || RHSShiftAmt.getOpcode() == ISD::ANY_EXTEND)) { + SDOperand LHSOp0 = LHSShiftAmt.getOperand(0); + SDOperand RHSOp0 = RHSShiftAmt.getOperand(0); + if (RHSOp0.getO...

...onvention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind != ISD::ANY_EXTEND && VT.isInteger()) { EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32); if (VT.bitsLT(MinVT)) VT = MinVT; } There have been a few discussions about this snippet on llvmdev in the past[1][2][3], and there seems to be a general consensus tha...

...p, + MachineFrameInfo * MFI) { I wonder if these can be moved to SelectionDAGISel? So it's handled during the sdisel phase of call lowering? if (isPPC64 && Arg.getValueType() == MVT::i32) { // FIXME: Should this use ANY_EXTEND if neither sext nor zext? @@ -1946,7 +2285,13 @@ SDOperand PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, if (GPR_idx != NumGPRs) { RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); } else { - MemOpChains.push_back(DAG.getStore(Chain, A...

...Dest should not be moved to SelectionDAGISel because they involve target knowledge (where to place the argument) and would involve moving the whole argument lowering to SelectionDAGISel. > > if (isPPC64 && Arg.getValueType() == MVT::i32) { > // FIXME: Should this use ANY_EXTEND if neither sext nor zext? > @@ -1946,7 +2285,13 @@ SDOperand > PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, > if (GPR_idx != NumGPRs) { > RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); > } else { > - MemOpChains....

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

On Thu, 13 Dec 2018 at 21:41, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 12/13/2018 6:25 AM, Alex Bradbury wrote: > > There's also likely to be cases where you want to calculate the demanded bits > > in order to determine if e.g. a W-suffixed instruction can be selected for > > `(somoeop (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))`. This is easy to match