search for: lanebitmask

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

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

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

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

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

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

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

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

...e 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've pinged it twice. That's too > frequent, the...

...ibc.so.6+0x3960c33dc5) #7 0x00000000026d4c42 bindingsErrorHandler(void*, std::string const&, bool) /d/en/johnsoni-0/gctools/llvm/lib/Support/ErrorHandling.cpp:127:0 #8 0x0000000001fdbc85 (anonymous namespace)::RegisterCoalescer::joinSubRegRanges(llvm::LiveRange&, llvm::LiveRange&, llvm::LaneBitmask, llvm::CoalescerPair const&) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:2695:0 #9 0x0000000001fdc3df (anonymous namespace)::RegisterCoalescer::mergeSubRangeInto(llvm::LiveInterval&, llvm::LiveRange const&, llvm::LaneBitmask, llvm::CoalescerPair&) /d/en/johnsoni-...

...The important 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) { >...

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

...at would prevent me from using more than 32 > lanes/subregisters? > > There is no known limitation. I chose uint32_t out of concern for > compiletime. Going up for uint64_t should be no problem, I'd be more > concerned about bigger types; hopefully all code properly uses the > LaneBitmask type instead of plain unsigned, you may need a few fixes in > that area. > (For history: We had a scheme in the past where the liveness tracking > mapped all lanes after lane 31 to the bit 32, however that turned out to > need special code in some places that turned out to be a constant...

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

...ionship of your target with X86? Are you trying to >> add something to it, or are you working on a separate target? >> >> -Krzysztof >> >> On 7/19/2017 4:47 PM, hameeza ahmed wrote: >> >> 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...

...e from using more than 32 lanes/subregisters? >> >> There is no known limitation. I chose uint32_t out of concern for compiletime. Going >> up for uint64_t should be no problem, I'd be more concerned about bigger types; >> hopefully all code properly uses the LaneBitmask type instead of plain unsigned, you >> may need a few fixes in that area. >> (For history: We had a scheme in the past where the liveness tracking mapped all lanes >> after lane 31 to the bit 32, however that turned out to need special code in some >> places...

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

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

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