search for: sdvalu

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

...// With SSE3 we can use fisttpll to convert to a signed i64; without + // SSE, we're stuck with a fistpll. + setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Custom); } // TODO: when we have SSE, these could be more efficient, by using movd/movq. @@ -4608,8 +4612,14 @@ SDValue Chain = DAG.getStore(DAG.getEntryNode(), dl, Op.getOperand(0), StackSlot, PseudoSourceValue::getFixedStack(SSFI), 0); + return BuildFILD(Op, SrcVT, Chain, StackSlot, DAG); +} +SDValue X86TargetLowering::BuildFILD(SDValue Op, MVT Sr...

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT, SDValue V1, SDValue V2, const SmallBitVector &Zeroable, const X86Subtarget &Subtarget,...

...32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to accomplish that: 1. Register the ZEXTLOAD for custom lowering: setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Custom); 2. Implement a custom lowering function: static SDValue LowerExtLoad(SDValue Op, SelectionDAG &DAG) { LoadSDNode *LD = dyn_cast<LoadSDNode>(Op.getNode()); ISD::LoadExtType ExtType = LD->getExtensionType(); if (LD->getExtensionType() == ISD::ZEXTLOAD) { DEBUG(errs() << "ZEXTLOAD\n"); SDValue Chain = LD->...

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in some places, e.g. in TargetLowering::LowerOperationWrapper, it seems like it is assumed only the first two of the above cases can happen because there we do: SDValue Res = LowerOperation(SDValue(N, 0), DAG); if (Res.getNode...

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

...ldr pc, [r3, +r0, lsl #2 .POOL_ADDR: .text .LJTI9_0_0: .data .LJTI9_0_0: .long .LBB9_2 .long .LBB9_5 .long .LBB9_7 .long .LBB9_4 .long .LBB9_8 .text The code for the lowering lives mostly in SDValue ARMTargetLowering::LowerBR_JT with some more heavy lifting done by ARMISD::WrapperJT My attempts at this are marked in the code below. My problem is to come up with the right item/value to put into the constant pool. SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) { SD...

Hi All, In XCore backend, I saw “ …... EVT VT = Op.getValueType(); SDValue Data = DAG.getNode(XCoreISD::CRC8, DL, DAG.getVTList(VT, VT), Op.getOperand(1), Op.getOperand(2) , Op.getOperand(3)); SDValue Crc(Data.getNode(), 1); SDValue Results[] = { Crc, Data }; return DAG.getMergeValues(Results, 2, DL); “ which is used to lowe...

...ion assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best reference for this. > >> In several places it seems like it is assumed that LowerOperation can >> return three kinds of values: >> * Something completely new. >> * SDValue() > > This tells the legalizer to treat the node as if it were marked Expand. > For loads and stores it tells the legalizer to treat the node as if > it were marked Promote. > >> * The same SDValue as LowerOperation was called on. > > This tells the legalizer that the in...

...In DAGToDAGISel when I try to pass it with four arguments and a return register it fails the assertion `ResNo < NumValues && "Illegal result number!"'. More specifically I am doing something like: EVT ReturnValueVT = Node->getValueType(0) ; SDValue ChainIn = Node->getOperand(0); SDValue Zero = CurDAG->getCopyFromReg(ChainIn, DL, Mips::ZERO, MVT::i32); SDValue op0 = Node->getOperand(2); SDValue op1 = Node->getOperand(3); SDValue op2= Node->getOperand(4); SDV...

...e, only the old value, > + // let LLVM add the comparison > + setOperationAction(ISD::ATOMIC_CMP_SWAP_WITH_SUCCESS, MVT::i32, Expand); > + > setTargetDAGCombine(ISD::FADD); > setTargetDAGCombine(ISD::FSUB); > setTargetDAGCombine(ISD::FMINNUM); > @@ -1168,6 +1174,7 @@ SDValue SITargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) const { > SIMachineFunctionInfo *MFI = MF.getInfo<SIMachineFunctionInfo>(); > return LowerGlobalAddress(MFI, Op, DAG); > } > + case ISD::ATOMIC_CMP_SWAP: return LowerATOMIC_CMP_SWAP(Op, DAG); >...

...CState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 261 8 llc 0x00000001000b62ac llvm::MBlazeTargetLowering::LowerCallResult(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 166 9 llc 0x00000001000b72c6 llvm::MBlazeTargetLowering::LowerCall(llvm::SDValu...

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

...de::mmo_iterator MemOp = MF->allocateMemRefsArray(1); MemOp[0] = cast<MemSDNode>(N)->getMemOperand(); cast<MachineSDNode>(LDW)->setMemRefs(MemOp, MemOp + 1); // Reshuffle LDW's results so that the first two match LOAD's result // type SDValue Unpack[] = { SDValue(LDW, 0), SDValue(LDW, 2), SDValue(LDW, 1) }; SDNode* NN = CurDAG->getMergeValues(Unpack, SDLoc(N)).getNode(); ReplaceUses(N, NN); CurDAG->RemoveDeadNode(N); With this code, I get correct-looking machine instructions, but the node order is all bot...

...ed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue MBlazeTargetLowering::LowerSELECT_CC(SDValue Op, > SelectionDAG &DAG) const { > SDValue LHS = Op.getOperand(0); > SDValue RHS = Op.getOperand(1); > SDValue TrueVal = Op.getOperand(2); > SDValue FalseVal = Op.getOperand(3); &gt...

...] Building CXX object lib/Target/AVR/CMakeFiles/LLVMAVRCodeGen.dir/AVRISelDAGToDAG.cpp.obj AVRISelDAGToDAG.cpp C:\llvm-build\lib\Target\AVR\AVRGenDAGISel.inc(596) : error C2664: 'llvm::SDNode *llvm::SelectionDAG::SelectNodeTo(llvm::SDNode *,unsigned int,llvm::MVT,llvm::MVT,llvm::MVT,const llvm::SDValue *,unsigned int)' : cannot convert parameter 6 from 'llvm::SDValue' to 'const llvm::SDValue *' No user-defined-conversion operator available that can perform this conv ersion, or the operator cannot be called I checked the generated the code: SDNode *Emit_2(const SDValu...

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue() means that Target gives up, and the common code is supposed to handle it. Returning Op, the unchanged argument, means that the Target is happy with the node as it is, and the...

.../// ARMPCLabelIndex - Keep track the number of ARM PC labels created. - /// + /// ARMPCLabelIndex - Keep track of the number of ARM PC labels created. unsigned ARMPCLabelIndex; + /// ARMJumpTableIndex - Keep track of the number ofJump Tables + unsigned ARMJumpTableIndex; SDValue LowerMemOpCallTo(CallSDNode *TheCall, SelectionDAG &DAG, const SDValue &StackPtr, const CCValAssign &VA, Index: lib/Target/ARM/ARMConstantPoolValue.h =================================================================== --- lib/Target/ARM/ARMConstantPoolValu...