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

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,

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

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

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

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

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, 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 getting following error.. error:Ran out of lanemask bits to represent subregister

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

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

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:

Yes, the arch is just as you said, something like AMD GPU, but Intel GPU don't have separate register file for 'scalar/vector'. In fact my idea of defining the register tuples was borrowed from SIRegisterInfo.td in AMD GPU. But seems that AMD GPU mainly support i32/i64 register type, while Intel GPU also support byte/short register type. So I have to start defining the registers from

> On Jan 22, 2016, at 1:23 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Jan 22, 2016, at 12:29 PM, Derek Schuff <dschuff at google.com <mailto:dschuff at google.com>> wrote: >> >> Here are 2 patches, which are independent of each other. >> >> The first splits PrologEpilogInserter into 2 parts :

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

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

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft