search for: getoperationaction

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType()); This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. i.e. it should be: case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::FP_TO_SINT: ca...

...y uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action = TLI.getOperationAction(Node->getOpcode(), > Node->getOperand(0).getValueType()); > > This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. > > i.e. it should be: > case ISD::SINT_TO_FP: > case ISD::UIN...

Hi! I noticed in the LegalizeDAG.cpp (SelectionDAGLegalize::LegalizeOp): case ISD::INIT_TRAMPOLINE: case ISD::FRAMEADDR: case ISD::RETURNADDR: // These operations lie about being legal: when they claim to be legal, // they should actually be custom-lowered. Action = TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)); if (Action == TargetLowering::Legal) Action = TargetLowering::Custom; break; What does this mean? Why does a target not request a node to be custom lowered if such a thing is needed? Also, I grepped for 'setOperationAction(ISD::T...

...nDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: { MVT::ValueType VT = Node->getValueType(0); // The only "good" option for this node is to custom lower it. switch (TLI.getOperationAction(Node->getOpcode(), VT)) { @@ -710,6 +710,7 @@ Result = LegalizeOp(Node->getOperand(0)); break; } + } break; case ISD::AssertSext: case ISD::AssertZext:

...ts(). ReplaceNodeResults() has the restriction that the result has to have the same number of values and types. This forces the lowering function to return a target defined custom i64 node. At the next legalization cycle ExpandIntegerResults() is called to expand this node causing an assert because getOperationAction doesn't operate on custom nodes. Am I doing something wrong? My goal is to provide an expansion for 64-bit division that unfortunately uses branches for a target that doesn't support 64-bit integers. Thanks, Javier On Thu, 10 Dec 2009 22:52:12 -0800, Evan Cheng <evan.cheng at apple.co...

Hmmm, a quick look at the documentation for TargetTransformInfo doesn't look like it. In LegalizeDAG.cpp it uses TLI.getOperationAction() to find out if an SDNode should be expanded by the legalizer or passed down to the target. That's what I need to know, but I need it in a pass pre-legalization. This seems like weird layering, though. Having an "optimization" pass be looking into specific types of SDNode doesn'...

...alized into constant pool loads // before the BUILD_VECTOR code can see them. It doesn't usually bite, // though, because BUILD_VECTORS usually get lowered into other nodes // which get legalized properly. SimpleFinishLegalizing = false; break; and then: case ISD::BUILD_VECTOR: switch (TLI.getOperationAction(ISD::BUILD_VECTOR, Node->getValueType(0))) { default: assert(0 && "This action is not supported yet!"); case TargetLowering::Custom: Tmp3 = TLI.LowerOperation(Result, DAG); if (Tmp3.getNode()) { Result = Tmp3; break; } // FALLTHROUGH case Targe...

...e BUILD_VECTOR code can see them. It doesn't usually bite, > // though, because BUILD_VECTORS usually get lowered into other nodes > // which get legalized properly. > SimpleFinishLegalizing = false; > break; > > and then: > > case ISD::BUILD_VECTOR: > switch (TLI.getOperationAction(ISD::BUILD_VECTOR, > Node->getValueType(0))) { > default: assert(0&& "This action is not supported yet!"); > case TargetLowering::Custom: > Tmp3 = TLI.LowerOperation(Result, DAG); > if (Tmp3.getNode()) { > Result = Tmp3; > bre...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; + case TargetLowering::Legal: break; + case TargetLowering::Custom: { + SDValue Tmp1 = TLI.LowerOperation(SDValue(Resul...

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a

See X86InstrInfo.td let usesCustomInserter = 1, isTwoAddress = 0, Defs = [EFLAGS] in def CMOV_GR8 : I<0, Pseudo, This creates a CMOV_GR8 pseudo instruction at isel time which can be expanded during scheduling time. Evan On Dec 10, 2009, at 11:46 AM, Javier Martinez wrote: > Hello, > > My expansion for an operation uses if and loops. How do I introduce > branches in the target

Hello, My expansion for an operation uses if and loops. How do I introduce branches in the target lowering stage? Do I have to create basic blocks, add the instructions to them and and add them to the machine function's basic block list? Thanks, Javier

On 4/3/2018 9:25 AM, Kevin Neal via llvm-dev wrote: > I'm working on the #pragma STDC FENV_ACCESS ON support, specifically > the support for a strict version of the FP to unsigned int conversion. > I've got a pass that runs and converts a new intrinsic into code that > uses the FP to signed int conversion code similar to how SelectionDAG > handles this now. Except that

...uot;); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) || getOperationAction(Op, NVT) == Promote); The first line in the do while loop is important, it just increments the type, starting at MVT::v4i8 until it hits a legal type. This seems broken to me. Here is what TOT LLVM has for its MVT list: v4i8 = 14, // 4 x i8 v8i8 = 15, // 8 x i8...

Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

...uot;); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) || getOperationAction(Op, NVT) == Promote); The first line in the do while loop is important, it just increments the type, starting at MVT::v4i8 until it hits a legal type. This seems broken to me. Here is what TOT LLVM has for its MVT list: v4i8 = 14, // 4 x i8 v8i8 = 15, // 8 x i8...

...do { > NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); > assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && > "Didn't find type to promote to!"); > } while (!isTypeLegal(NVT) || > getOperationAction(Op, NVT) == Promote); > > The first line in the do while loop is important, it just increments > the type, starting at MVT::v4i8 until it hits a legal type. > > This seems broken to me. > Here is what TOT LLVM has for its MVT list: > v4i8 = 14, // 4 x i8 >...