Displaying 20 results from an estimated 800 matches similar to: "Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register"
2016 Sep 18
4
Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
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
2017 Jul 28
2
Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
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.
2017 Jul 28
0
Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
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:
2017 Jul 14
2
error:Ran out of lanemask bits to represent subregister
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
2017 Jul 19
2
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
2017 Jul 19
2
error:Ran out of lanemask bits to represent subregisterr
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
>
2017 Jul 14
2
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
2017 Jul 14
3
error:Ran out of lanemask bits to represent subregister
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
2017 Jul 19
2
error:Ran out of lanemask bits to represent subregisterr
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
2017 Jul 19
2
error:Ran out of lanemask bits to represent subregisterr
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,
2017 Jul 19
2
error:Ran out of lanemask bits to represent subregisterr
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
2017 Jul 19
2
error:Ran out of lanemask bits to represent subregisterr
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
2017 Jul 19
5
error:Ran out of lanemask bits to represent subregisterr
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 <=
2017 Jul 14
2
error:Ran out of lanemask bits to represent subregister
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
2017 Jul 20
2
error:Ran out of lanemask bits to represent subregisterr
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
2016 Aug 23
2
How to describe the RegisterInfo?
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
2013 Oct 07
1
[LLVMdev] Subregister liveness tracking
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
2020 Nov 19
1
Problems with undef subranges in identity copies
Hi,
I'm stuck trying to fix a variety of problems that occur with undef
subregisters when the register coalescer eliminates identity
copies. The fundamental problem is complexity from the fact that undef
values are a special case since they don't have an associated
VNInfo/Segment unless the value is used across blocks.
For example, in this case, %0 has 2 subregisters sub0 and sub1:
2013 Oct 08
2
[LLVMdev] Subregister liveness tracking
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
2013 Oct 08
0
[LLVMdev] Subregister liveness tracking
What I didn't mention in r192119 is that mthi/lo clobbers the other
sub-register only if the contents of hi and lo are produced by mult or
other arithmetic instructions (div, madd, etc.) It doesn't have this
side-effect if it is produced by another mthi/lo. So I don't think making
mthi/lo clobber the other half would work.
For example, this is an illegal sequence of instructions,