search for: isd

...HasVectorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRI...

...HasVectorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRI...

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

...onDAG. void RemoveDeadNodes(); Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 72159) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -117,15 +117,18 @@ setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote); setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand); } else { - if (!UseSoftFloat && !NoImplicitFloat && X86ScalarSSEf64) { + if (!UseSoftFloat && X86ScalarSSEf64) { // We have an impenetrably clever algor...

...uot;Expanded integer type size not a power of two!"); DebugLoc dl = N->getDebugLoc(); // Get the incoming operand to be shifted. SDValue InL, InH; GetExpandedInteger(N->getOperand(0), InL, InH); SDValue NVBitsNode = DAG.getConstant(NVTBits, ShTy); SDValue Amt2 = DAG.getNode(ISD::SUB, dl, ShTy, NVBitsNode, Amt); SDValue Cmp = DAG.getSetCC(dl, TLI.getSetCCResultType(ShTy), Amt, NVBitsNode, ISD::SETULT); SDValue Lo1, Hi1, Lo2, Hi2; switch (N->getOpcode()) { default: llvm_unreachable("Unknown shift"); case ISD::SHL: //...

...<const XXXSubtarget&> (DAG.getSubtarget()); XXXCC::CondCodes TCC; getFPCCtoXXCC(CC,TCC); TargetCC = DAG.getConstant(TCC, dl, MVT::i8); if (STI.useHardFloat()) { // if fcmp instruction is available use it SDValue Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, TargetCC); return DAG.getNode(XXXISD::BR_CC, dl, Op.getValueType(), Chain, Dest, TargetCC, Flag); } else { // else generate library call DAG.getTargetLoweringInfo().softenSetCCOperands(DAG, MVT::f32, LHS, RHS,...

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3&q...

...hould consider? > > -Rich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > I needed to do exactly the same for my target. I set ISD::ADD to be custom expanded (setOperationAction(ISD::ADD, MVT::i64, Custom)) and the same for ISD::SUB. I then added the following code to my target to do the expansion: ExpandADDSUB(SDNode *N, SelectionDAG &DAG) { assert(N->getValueType(0) == MVT::i64 && (N->getOpcode() == ISD...

On Mon, Nov 30, 2009 at 7:22 PM, Javier Martinez <javier at jmartinez.org> wrote: > Hello, > > I'm working in adding support for 64-bit integers to my target. I'm using > LLVM to decompose the 64-bit integer operations by using 32-bit registers > wherever possible and emulating support where not. When looking at the bit > shift decomposition I saw what seems to be a

...; (DAG.getSubtarget()); > XXXCC::CondCodes TCC; > getFPCCtoXXCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > if (STI.useHardFloat()) { > // if fcmp instruction is available use it > SDValue Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > return DAG.getNode(XXXISD::BR_CC, dl, Op.getValueType(), > Chain, Dest, TargetCC, Flag); > } > else { > // else generate library call > DAG.getTargetLoweringInfo().softenSetCCOper...

...lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (.../trunk) (revision 2118) +++ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (.../branches/llvm-spu) (revision 2118) @@ -2683,10 +2683,24 @@ case ISD::ROTR: Tmp1 = LegalizeOp(Node->getOperand(0)); // LHS Tmp2 = LegalizeOp(Node->getOperand(1)); // RHS - - assert(TLI.isOperationLegal(Node->getOpcode(), Node->getValueType(0)) && - "Cannot handle this yet!"); Result = DAG.UpdateNodeOp...

...ently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand); I thought that I could solve this problem by: setOperationAction(ISD::VAARG, MVT::i1, Promote); AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); setOperationAction(ISD::VAARG, MVT::i8, Promote); AddPromotedToType (ISD::VAARG, MVT::i8, MVT::i64)...

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

...comparison to un > comparison + OR + ordered comparison ? > Can I do it by adding required SDNodes ? > for example I am trying to do it in LowerBR_CC as shown below: > getFPCCtoMBCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > if (isUnordered) { > TCC = XXX::COND_UN; > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > SDValue UnComp = DAG.getNode(XXX::FCMP, dl, MVT::Glue, LHS, RHS, >...

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

...Z_ZERO_UNDEF and CTPOP. > > -Eli > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Joan Lluch via llvm-dev > Sent: Monday, June 10, 2019 8:31 AM > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] [llvm-dev] Bug: Library functions for ISD::SRA, ISD::SHL, and ISD::SRL > > LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. > > The library functions defined in RuntimeLibCalls.def (among others) are these: > > HANDLE_LIBCALL(SRA_I16...

...er types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended to 64 bits on the stack and the default logic > > provided in LegalizeDAG does not use that convention. Specifically, > > for these targets we have: setOperationAction(ISD::VAARG, > > MVT::Other, Expand); I thought that I could solve this problem by: > > setOperationAction(ISD::VAARG, MVT::i1, Promote); > > AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); > > setOperationAction(ISD::VAARG, MVT::i8, Promote); > >...

...andling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for these targets we have: > setOperationAction(ISD::VAARG, MVT::Other, Expand); > I thought that I could solve this problem by: > setOperationAction(ISD::VAARG, MVT::i1, Promote); > AddPromotedToType (ISD::VAARG, MVT::i1, MVT::i64); > setOperationAction(ISD::VAARG, MVT::i8, Promote); > AddPromotedToType (I...

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