Craig Topper via llvm-dev
2017-Jul-19 21:18 UTC
[llvm-dev] 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 > is no point in using uint64_t, you need something wider. > > -Krzysztof > > On 7/19/2017 3:25 PM, hameeza ahmed wrote: > > 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, Krzysztof Parzyszek > > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: > > > > It is possible that you have more than 64 lanes. In such case you > > would need to reimplement LaneBitmask with a larger underlying type. > > Most of the functionality is already localized to the header file, > > the only exception may be the "getAsInteger" function. It shouldn't > > be too hard to fix up the uses to deal with a different underlying > type. > > > > -Krzysztof > > > > > > On 7/19/2017 2:56 PM, hameeza ahmed wrote: > > > > 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 <mailto:craig.topper at gmail.com> > > <mailto:craig.topper at gmail.com <mailto:craig.topper at gmail.com>>> > > wrote: > > > > Did you change the hardcoded 32 right before the line that > > prints > > that error in CodeGenRegisters.cpp to 64? > > > > ~Craig > > > > On Wed, Jul 19, 2017 at 11:38 AM, hameeza ahmed > > <hahmed2305 at gmail.com <mailto:hahmed2305 at gmail.com> > > <mailto:hahmed2305 at gmail.com <mailto:hahmed2305 at gmail.com>>> > wrote: > > > > 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 > > > > > sub_32768bit_hi_then_sub_16384bit_hi_then_sub_8192bit_hi_then_sub_4096bit_hi_then_sub_2048bit_hi_then_sub_32bit_hi_then > > > > Now what to do? > > > > Please help. > > > > > > On Wed, Jul 19, 2017 at 5:57 PM, Krzysztof Parzyszek > > <kparzysz at codeaurora.org > > <mailto:kparzysz at codeaurora.org> <mailto:kparzysz at codeaurora.org > > <mailto:kparzysz at codeaurora.org>>> wrote: > > > > Hi, > > The LaneBitmask is implemented in > > include/llvm/MC/LaneBitmask.h. You will need to > > change the > > underlying type and the associated member functions. > > If you have a large number of lanes, you will need > to > > replace it with a type that can contain as many > > independent > > bits as you need (BitVector would be an ultimate > > solution). You may run into some problems with the > > uses of the member > > function "getAsInteger", but you can change those to > > something equivalent according to the type you use. > > > > -Krzysztof > > > > > > On 7/19/2017 3:51 AM, hameeza ahmed wrote: > > > > 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 getting following error.. > > > > error:Ran out of lanemask bits to represent > > subregister > > > > > sub_32768bit_hi_then_sub_16384bit_hi_then_sub_8192bit_hi_then_sub_4096bit_hi_then_sub_2048bit_hi_then_sub_32bit_hi_then > > > > now how to increase lanemask bits? what changes > are > > required?? > > > > > > Kindly help. > > > > > > > > > > > > -- Qualcomm Innovation Center, Inc. is > > a member of Code Aurora > > Forum, hosted by The Linux Foundation > > > > > > > > > > > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > hosted by The Linux Foundation > > > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170719/6447b521/attachment.html>
Krzysztof Parzyszek via llvm-dev
2017-Jul-19 21:26 UTC
[llvm-dev] error:Ran out of lanemask bits to represent subregisterr
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 example there was a hard coded compare with 32 in tablegen until I > fixed it recently.This is most likely the only example. I actually tested it with uint64_t (but without exceeding 32 lanes). -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Craig Topper via llvm-dev
2017-Jul-19 21:30 UTC
[llvm-dev] 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 example there was a hard coded compare with 32 in tablegen until I > > fixed it recently. > > This is most likely the only example. I actually tested it with > uint64_t (but without exceeding 32 lanes). > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170719/b4b8323e/attachment.html>