search for: machinevaluetypes

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

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

...6 9:31 PM To: Marcello Maggioni <mmaggioni at apple.com> Cc: Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] dumb question about tblgen 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<mailto: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...

Dumb question about llvm-tblgen for "XyzGenInstrInfo.inc" If I have a pattern in my dot-td-file like this [(set i32:$dst (add i32:$rs1, i32:$rs2))] The question is where does the token "i32" come from, I don't see any definitions for i1, i8, i16, i32, ... in include/llvm/Target/*.td while I do see definitions for tokens like

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

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 for your instruction? So that you would have an ADD instruction like %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 What kind of problematic regalloc are you trying to avoid with introducing a new backend data type? Marcello > On

Hi Peter, I would recommend looking into the implementation of the matcher if you want to add more builtin types: utils/TableGen//DAGISelMatcherGen.cpp That being said, you can define your own types without having to go through that hassle. E.g., from AArch64 def simm9 : Operand<i64>, ImmLeaf<i64, [{ return Imm >= -256 && Imm < 256; }]> { let ParserMatchClass =

Hi, Here's llvm-tblgen -print-records message: def LOADbos { // Instruction ABCInst ABCInstMMEMrr field bits<32> Inst = { 0, 0, 0, 0, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; field bits<32> SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

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

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

Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish

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

You seem to be using old LLVM sources---changing this many files for supporting a different width LaneBitmask is no longer necessary. Also, boost is not a current requirement for building LLVM and it's unlikely that requiring it for that purpose alone is justified. -Krzysztof On 7/28/2017 6:30 AM, Alex Susu via llvm-dev wrote: > Hello. > I come back to this older thread.

Hello. I come back to this older thread. As I've said before, I managed to patch the various files from the back end related to lanemask in order to support at most 1024 vector lanes. For this I am using a 1024-bit long lanemask of type uint1024_t from boost::multiprecision, instead of uint32_t. For this I changed the following LLVM source files:

I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On

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

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