search for: lanemask

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

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 larger type than "unsigned" or "uint32_t". ~Craig On Fri, Jul 14, 2017 at 10:09 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Your first post was 6 hours ago and you...

...., 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 represent subregister sub_16_033". To handle this limitation, I started editing the files where this error comes from: llvm/utils/TableGen/CodeGenRegisters.h llvm/utils/TableGen/CodeGenRegisters.cpp More exactly, the error comes from the fact the member LaneMa...

...ying 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_32bit now how to increase lanemask bits? what changes are required in IntrinsicEmitter.cpp file?? Please reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...

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

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

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

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

...ying 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 larger type than "unsigned" or "uint32_t". >> >> ~Craig >> >> On Fri, Jul 14, 2017 at 10:09 AM, Tim Northover <t.p.northover at gmail.com>...

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: [repository]/llvm/utils/TableGen/CodeGenRegisters.cpp [repository]/llvm...

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

...likely 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. > > 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: > [repository]/llvm/utils/TableGen/CodeGenRegisters.cpp &gt...

...t; >> On Wed, Jul 19, 2017 at 11:38 AM, hameeza ahmed >> <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: >> >> >>...

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

...cting a Log call and another in the >> parser? >> >> On Wed, Jul 19, 2017 at 2:26 PM Krzysztof Parzyszek < >> kparzysz at codeaurora.org <mailto: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 recent...

...nt thing would be to add something like MachineRegisterInfo::setVirtRegsAfterRegalloc() and MachineRegisterInfo::getVirtRegsAfterRegalloc(). Because I would assume that we will find more examples like the following (from MachineBasicBlock): > > void addLiveIn(MCPhysReg PhysReg, LaneBitmask LaneMask = ~0u) { > LiveIns.push_back(RegisterMaskPair(PhysReg, LaneMask)); > } > > this needs to be changed to support VRegs. But if we do that change, I'd like to change it to something like this: > > void addLiveIn(unsigned Reg, LaneBitmask LaneMask = ~0u) { > asser...

...;mailto:kparzysz at codeaurora.org> >> <mailto:kparzysz at codeaurora.org >> <mailto: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...

...LICIT_DEF is inserted in place to give a corresponding instruction / value number for the cross-block undef value. However in this situation, there's no specific subregister index associated to define. It's an arbitrary set of lane masks, and there's no way to go backwards from a set of lanemasks to a set of subregister indexes to implicitly def. I've also hit a second family of this same fundamental problem with a slight variant of the testcase: bb.0: liveins: $vgpr0 undef %0.sub1:vreg_64 = COPY killed $vgpr0 bb.1: %1:vreg_64 = COPY killed %0 %0:vreg_64 = COPY...

...ss<"IntelGPU", [i32, f32], 32, (add gpr_d)>; def RegD_SIMD8 : RegisterClass<"IntelGPU", [i32, f32], 32, (add gpr_d_simd8)> { } This is easy for me to define the register alias information. But it won't works! the tablegen exit and tells me: "error:Ran out of lanemask bits to represent subregister sub1_then_sub1" Anybody know what's wrong here? - Ruiling 2016-08-23 11:45 GMT+08:00 <escha at apple.com>: > If I understand right, on this arch, ‘uniform’ refers to values that only > take one lane of register file instead of SIMD-width lanes,...

...range) to LiveRange::Segment. LiveInterval is made a subclass of LiveRange, other code paths like register units liveness use LiveRange instead of LiveInterval now. * Introduce a linked list of SubRange objects to the LiveInterval class. A SubRange is a subclass of LiveRange and contains a LaneMask indicating which subregisters are represented. * Various algorithms have been adapted to calculate/preserve subregister liveness. * The register allocator has been adapted to track interference at the subregister level (LaneMasks are mapped to register units) Note that SubRegister livenes...