search for: machinevaluetype

The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with a class for every type in MachineValueTypes.h On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don’t quite follow why you are doing something like this. > > What is the advantage of this instead of just attaching the AddrRegs > regsister class as the register class...

There is a comment in MachineValueTypes.h in the enum. // If you change this numbering, you must change the values in // ValueTypes.td as well! Other = 0, // This is a non-standard value I don't think the .td include can be fixed easily. Tablegen doesn't support include guards and can only includ...

...ncluded, Being indirectly included from “include/llvm/IR/Intrinsics.td” isn’t exactly obvious :=(( Would it be possible move the #include into “Target.td” ? Also, in “ValueTypes.td” there is a comment about needing to keep it coordinated With “MahineValueType.h”, but there is no such comment in “MachineValueType.h”, Would it be possible for someone to add such a complementary comment ? Thanks, --Peter Lawrence. From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Wednesday, May 25, 2016 9:31 PM To: Marcello Maggioni <mmaggioni at apple.com> Cc: Lawrence, Peter <c_plawre at qca.qualcom...

...i16, i32, ... in include/llvm/Target/*.td while I do see definitions for tokens like "set", "add", ... coming from include/llvm/Target/TargetSelectionDAG.td presumably these tokens are related to the enum in include/llvm/CodeGen/MachineValueType.h but how does tblgen know about them, To put the question into context, if I add an item to the enum in "MachineValueType.h" What do I do about "error: Variable not defined:" Coming from tblgen when I try to use it in my dot-td-file, I've already tried re...

Quentin, My real problem is that my target has separate address and data registers. The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h” And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass); And I have an override for virtual TargetLowering::getPointerTy() that returns MVT::p32, And some other minor changes that altogether cause virt-regs that contain pointers To get my AddrRegs reg-class rather than t...

...rg> wrote: > > Quentin, > My real problem is that my target has separate address and data registers. > The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as > Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h” > > And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass); > > And I have an override for virtual TargetLowering::getPointerTy() that returns MVT::p32, > > And some other minor changes that altogether cause virt-regs that contain pointers > To get...

...t; include/llvm/Target/*.td > > while I do see definitions for tokens like “set”, “add”, … > coming from > include/llvm/Target/TargetSelectionDAG.td > > presumably these tokens are related to the enum in > include/llvm/CodeGen/MachineValueType.h > but how does tblgen know about them, > > > To put the question into context, if I add an item to the enum in “MachineValueType.h” > What do I do about > “error: Variable not defined:” > Coming from tblgen when I try to use it in my dot-td-file, > I’v...

...*sext (i16 (bitconvert i16v:$roffset))*), i32:$rshift))))]; ..... i16v is a new type we added, same as i16, only name differ. While -gen-dag-isel, hit the following issue: Value type size is target-dependent. Ask TLI. UNREACHABLE executed at /home/nancy/rpp_llvm/rpp_clang/llvm/include/llvm/Support/MachineValueType.h:643! Is that a TableGen bug? llvm 8.0.0 version. -- Best Regards, Yu Rong Tan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190927/d2123760/attachment.html>

Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in debug mode. llvm-tblgen: /utils/TableGen/CodeGenDAGPatterns.cpp:57: llvm::EEVT::TypeSet::TypeSet(MVT::SimpleValueType, llvm::TreePattern &): Assertion `(VT < MVT::LAST_VALUETYPE || VT ==...

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our target is 16 bits. When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had...

...(Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to the normal pow-of-2 types). And we have vectors of > those (v2i40, v4i40). > > And the byte size in our target is 16 bits. > > When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 > bits. > > When storing a v4i40 vector it will be s...

...with these types v32f32, v32f64.... in llvm which are >> undefined in the backend? >> But v32i32, v32i64 are already defined so i am able to use these. >> >> but for other types such as v32f32, v32f64 although i have defined them >> appropriately in all the files like machinevaluetype.h, valuetypes.cpp >> etc. i have checked it many times but still getting the following error >> when build in debug mode. >> >> llvm-tblgen: /utils/TableGen/CodeGenDAGPatterns.cpp:57: >> llvm::EEVT::TypeSet::TypeSet(MVT::SimpleValueType, llvm::TreePattern &): >...

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

...> that I needed are v128i1, v128i16, also v1024f64). The files I changed are: > [repository]/llvm/include/llvm/CodeGen/ValueTypes.td > [repository]/lib/IR/ValueTypes.cpp > [repository]/include/llvm/IR/Intrinsics.td > [repository]/llvm/include/llvm/CodeGen/MachineValueType.h > [repository]/llvm/utils/TableGen/CodeGenTarget.cpp > Please let me know if you want to commit these changes also - they > are rather complex in the sense there are a lot of small dependencies > for these types. > > Best regards, > Alex > > &gt...

...etc - examples of types that I needed are v128i1, v128i16, also v1024f64). The files I changed are: [repository]/llvm/include/llvm/CodeGen/ValueTypes.td [repository]/lib/IR/ValueTypes.cpp [repository]/include/llvm/IR/Intrinsics.td [repository]/llvm/include/llvm/CodeGen/MachineValueType.h [repository]/llvm/utils/TableGen/CodeGenTarget.cpp Please let me know if you want to commit these changes also - they are rather complex in the sense there are a lot of small dependencies for these types. Best regards, Alex On 9/20/2016 12:48 PM, Alex Susu wrote: > He...

...llvm which are >>>> undefined in the backend? >>>> But v32i32, v32i64 are already defined so i am able to use these. >>>> >>>> but for other types such as v32f32, v32f64 although i have defined them >>>> appropriately in all the files like machinevaluetype.h, valuetypes.cpp >>>> etc. i have checked it many times but still getting the following error >>>> when build in debug mode. >>>> >>>> llvm-tblgen: /utils/TableGen/CodeGenDAGPatterns.cpp:57: >>>> llvm::EEVT::TypeSet::TypeSet(MVT::SimpleV...

...AM, Björn Pettersson A wrote: (Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our target is 16 bits. When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had...

In the definition of register classes, have you provided any value types for each class? -Krzysztof On 1/9/2019 7:19 PM, m m via llvm-dev wrote: > The file that is causing this assertion contains only 3 include statements > > |//===-- ABCOther.td - Describe the ABC Target Machine ----*- tablegen > -*-===// // // >

Hi, My target can support non-power-of-2-sized vectors. My first thought is to add the non-power-of-2 vector type to the function MVT::getVectorVT in MachineValueType.h, is this the correct approach? I see code that checks for isPowOf2 for vectors in lib<https://github.com/llvm-mirror/llvm/tree/master/lib>/CodeGen<https://github.com/llvm-mirror/llvm/tree/master/lib/CodeGen>/TargetLoweringBase.cpp // FIXME: We don't support non-power-of-2-sized...

Hello. I've managed to patch the various files from the back end related to lanemask - now I have 1024-bit long lanemask. But now I get the following error when giving make llc: <<error:unhandled vector type width in intrinsic!>> This error comes from this file https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp, comes from the