similar to: error:Ran out of lanemask bits to represent subregister

please tell me how to solve this lanemask bits issue? how to increase lanemask bits? On Fri, Jul 14, 2017 at 8:33 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > > Hello, > i am trying to construct a register of size 65536 bit by combining 2 > registers of 32768 bits. both the 32768 bit registers are different so i > have to use the following method > > let

Do your 32768 registers also have sub registers? I can't tell you exactly what to change. I'm not familiar with the code. I would just be running grep or something. ~Craig On Fri, Jul 14, 2017 at 10:23 AM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > Thank you so much. I think there is no issue with my definitions since i > have to use larger registers i.e 65536 bit

This error indicates that its trying to create a lane mask larger than 32 bits. Without seeing all of your subregister definitions I can't tell if that's correct of if there's something wrong with your register definitions. If it is correct then you need to change all the associated LaneMask code in CodeGenRegisters.cpp, include/llvm/MC/LaneBitMask.h and probably elsewhere to use a

Hello, Mr. krzysztof I have seen similar question asked by you on llvm group. Could you please help me here to address this issue. i am trying to construct a register of size 65536 bit by combining 2 registers of 32768 bits. both the 32768 bit registers are different so i have to use the following method let SubRegIndices = [sub_32768bit, sub_32768bit_hi], CoveredBySubRegs = 1 in but i am

Thank You. I have replaced all the occurrences of unsigned with uint64_t in Lanemask.h and in all other related files like codegenregisters.cpp, codegenregisters.h, MIParser.cpp etc... Also i changed Log2_32 to Log2_64 and replaced 4 with 8 in codegenregisters.cpp, but still getting the same error: error:Ran out of lanemask bits to represent subregister

As you mentioned i changed 32 to 64 but now some new errors come which require to change unsigned to uint64_t in mentioned files. i have changed in mentioned files but still errors come to change in other files.. What to do? On Thu, Jul 20, 2017 at 12:08 AM, Craig Topper <craig.topper at gmail.com> wrote: > Did you change the hardcoded 32 right before the line that prints that >

You are right. Regarding lanes i can comment only when the other things run fine. Here I am stuck with unsigned vs uint64_t. it looks as if i need to replace each occurrence of unsigned with uint64_t. Should i do it for complete llvm folder or codegen only?? i am continuously getting such errors which require changing unsigned with uint64_t. What to do now??? On Thu, Jul 20, 2017 at 1:03 AM,

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=

LaneMask isn't as self contained as it should be. 64 bits is enough here. The problem is accidental leaking of the current size. For example there was a hard coded compare with 32 in tablegen until I fixed it recently. On Wed, Jul 19, 2017 at 1:36 PM Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > LaneBitmask should be self-contained. If 64 bits aren't enough, there

Hello. In my TableGen back end description I need to use more than 32 (e.g., 128, 1024, etc) subregisters per register for my research SIMD processor. I have used so far with success 32 subregisters. However, when using 128 subregisters when I now give the command: llvm-tblgen -gen-register-info Connex.td I get an error message "error:Ran out of lanemask bits to

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

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:

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.

What about the static asserts protecting a Log call and another in the parser? On Wed, Jul 19, 2017 at 2:26 PM Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/19/2017 4:18 PM, Craig Topper wrote: > > LaneMask isn't as self contained as it should be. 64 bits is enough > > here. The problem is accidental leaking of the current size. > > > > For

Hello Krzysztof, The R_CASS definition is as follows: class R_CASS<string n, bits<16> Enc, list<Register> subregs = []> : Register<n> { let Namespace = "X86"; let HWEncoding = Enc; let SubRegs = subregs; } On Thu, Jul 20, 2017 at 4:14 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > I tried reproducing the problem, but the file

The field Num seems to have no meaning. It is not recognized by the backend tools. It does not hurt anything but should not be there. // We have banks of 32 registers each. class MipsReg<string n> : Register<n> { field bits<5> Num; let Namespace = "Mips"; } class ARMReg<bits<4> num, string n, list<Register> subregs = []> : Register<n> {

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

At least or Mips, this line seems extraneous. I removed it and and all consequential uses of that (400 changes to MipsRegisterInfo.td) and make check for mips still works. Am running our full test sequence now. This Mips part of this was copied from the Sparc port. Similar problems in other ports. Seems this has just been copied many times to new ports. On 03/21/2012 02:58 PM, reed kotler

i have loop index I. I want to increment it by 1. How to do this in registerinfo.td. I m trying following but getting error. let SubRegIndices = [sub_32bit, sub_32bit_hi], CoveredBySubRegs = 1 in { foreach I = 0-255 in { m=add(I,1); def R_#J#_REG64b_#I : R_P<"R_"#J#"_R64b_"#I, !shl(I,2), [!cast<R_P>("R_"#J#"_REG32b_"#I),

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira