search for: mvt

Displaying 20 results from an estimated 883 matches for "mvt".

Did you mean: mvr
2008 Sep 08
0
[LLVMdev] adde/addc
...___________________________ > 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::ADD || N->getOpcode() == ISD::SUB) && "Unkno...
2012 Mar 23
2
[LLVMdev] Fixing VAARG on PPC64
...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); setO...
2013 Aug 05
2
[LLVMdev] Promote MVT::f32 load/store to MVT::i32 cause infinite loop in LegalizeDAG?
On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote); AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. What is going on? I still have the following:(but I...
2012 Mar 23
2
[LLVMdev] Fixing VAARG on PPC64
...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...
2013 Aug 05
0
[LLVMdev] Promote MVT::f32 load/store to MVT::i32 cause infinite loop in LegalizeDAG?
...oad of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach (to simplify > things) : > > > > setOperationAction(ISD::STORE, MVT::f32, Promote); > > AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); > > setOperationAction(ISD::LOAD, MVT::f32, Promote); > > AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); > > > > Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. &gt...
2013 Aug 05
1
[LLVMdev] Promote MVT::f32 load/store to MVT::i32 cause infinite loop in LegalizeDAG?
...wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); > AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); > setOperationAction(ISD::LOAD, MVT::f32, Promote); > AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); > > Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. > What is going on? >...
2020 Jun 30
5
[RFC] Semi-Automatic clang-format of files with low frequency
I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good
2008 Sep 08
6
[LLVMdev] adde/addc
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
2012 Mar 23
0
[LLVMdev] Fixing VAARG on PPC64
...ger 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, M...
2018 Apr 10
1
64 bit mask in x86vshuffle instruction
...4 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, SelectionDAG &DAG) { // If we have a single input to the zero element, i...
2012 Mar 23
0
[LLVMdev] Fixing VAARG on PPC64
...t;> 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); >>> A...
2017 Mar 07
2
[RFC][SVE] Extend vector types to support SVE registers.
Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding question is whether you think the new MVTs are acceptable and in addition if you agree it makes sense to replicate the change to the IR's type system so that all vector MVTs are representable wi...
2016 Mar 15
2
how to type-legalize a dag
...at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > I'd like to ask you another question (if you don't mind). My EsenciaISelLowering.cpp contains the following code in the EsenciaTargetLowering class constructor: setOperationAction(ISD::BR_CC, MVT::i32, Custom); setOperationAction(ISD::BR_CC, MVT::f32, Custom); setOperationAction(ISD::BR_JT, MVT::Other, Expand); setOperationAction(ISD::BRCOND, MVT::Other, Expand); setOperationAction(ISD::SETCC, MVT::i32, Expand); setOperationAction(ISD...
2009 Jun 29
2
[LLVMdev] Inserting nodes into SelectionDAG (X86)
Sorry to ask again, but I still can't get it right. The following code compiles and runs, but produces no instructions: Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32)); Ops.push_back(DAG.getConstant(1, MVT::i32)); DAG.getNode(ISD::ADD, DAG.getVTList(MVT::i32), &Ops[0], Ops.size()); I reckon that has something to do with the fact that I am not using the Chain object. But as soon as I try to chain that node, llc tells me that I have the wrong number...
2009 Jul 01
3
[LLVMdev] Inserting nodes into SelectionDAG (X86)
On Jul 1, 2009, at 2:22 PMPDT, Dan Gohman wrote: >> Ops.push_back(DAG.getConstant(1, MVT::i32)); >> Chain = DAG.getNode(ISD::ADD, DAG.getVTList(MVT::Other, MVT::i32), >> &Ops[0], Ops.size()); >> >> Isn't that the way how it is supposed to work? > > ADD does not use a chain, so there's no chain operand, or > MVT::Other result for it in an ADD...
2009 Apr 13
1
[LLVMdev] Porting LLVM backend is no fun yet
Dan Gohman wrote: > There certainly are wishlist items for TableGen and TableGen-based > instruction descriptions, though I don't know of an official list. > Offhand, > a few things that come to mind are the ability to handle nodes with > multiple results, Is there an official workaround, BTW? - Volodya
2009 Jul 03
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal = DAG.getCopyFromReg(Chain, X86::EAX, MVT::i32); SDValue inc = DAG.getNode(ISD::ADD, MVT::i32, eaxVal, DAG.getConstant(1, MVT::i32)); InFlag = SDValue(); Chain = DAG.getCopyT...
2012 Dec 05
2
[LLVMdev] [RFC] Replacing EVT:s with MVT:s (when possible)
On 3 Dec 2012, at 23:45, Chris Lattner wrote: > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything that takes a legal machine type should take an MVT. A side i...
2012 Dec 03
2
[LLVMdev] [RFC] Replacing EVT:s with MVT:s (when possible)
There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAc...
2014 Dec 05
3
[LLVMdev] default operation action
...ive supported 32 bits registers, to handle 8 bits value operations, I want to do promote. and to support 64 bit operations, I want to expand. If I can set up the operation actions for the same type globally, then I can avoid to list all the operations with the same action . like // expand type MVT::i64 to MVT::i32 for all the operations instead of “ setOperationAction( ISD::ADD, MVT::i64, Expand); setOperationAction( ISD::SUB, MVT::i64, Expand); setOperationAction( ISD::MUL, MVT::i64, Expand); ….. “ Or LLVM is smart enough to do it buy default? best kevin