Alex Susu via llvm-dev
2016-Sep-08 13:37 UTC
[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
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 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 LaneMask of the classes CodeGenSubRegIndex and CodeGenRegister is unsigned (i.e., 32 bits). So for every lane/subregister we require a bit from the type LaneMask. I plan to use type long (or even type int1024_t from the boost library, header cpp_int.hpp) for LaneMask and change accordingly the methods handing the type. Is there are any limitation I am not aware of (maybe in LLVMV's register allocator) that would prevent me from using more than 32 lanes/subregisters? Thank you very much, Alex
Matthias Braun via llvm-dev
2016-Sep-12 22:47 UTC
[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
> On Sep 8, 2016, at 6:37 AM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 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 LaneMask of the classes CodeGenSubRegIndex and CodeGenRegister is unsigned (i.e., 32 bits). So for every lane/subregister we require a bit from the type LaneMask. > I plan to use type long (or even type int1024_t from the boost library, header cpp_int.hpp) for LaneMask and change accordingly the methods handing the type. > > Is there are any limitation I am not aware of (maybe in LLVMV's register allocator) that 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 source of bugs that typically only happened in big and hard to debug inputs so we moved away from this scheme). - Matthias
Alex Susu via llvm-dev
2016-Sep-18 21:14 UTC
[llvm-dev] 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 fact there is no IIT_V128 (nor IIT_V256), and they is a switch case using them in method static void EncodeFixedType(Record *R, std::vector<unsigned char> &ArgCodes, std::vector<unsigned char> &Sig). Is there any reason these enum IIT_Info ( IIT_V128, IIT_V256) are not added in file /IntrinsicEmitter.cpp? Thank you, Alex On Tue, Sep 13, 2016 at 1:47 AM, Matthias Braun <mbraun at apple.com> wrote:> > > On Sep 8, 2016, at 6:37 AM, Alex Susu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 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 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 LaneMask of > the classes CodeGenSubRegIndex and CodeGenRegister is unsigned (i.e., 32 > bits). So for every lane/subregister we require a bit from the type > LaneMask. > > I plan to use type long (or even type int1024_t from the boost > library, header cpp_int.hpp) for LaneMask and change accordingly the > methods handing the type. > > > > Is there are any limitation I am not aware of (maybe in LLVMV's > register allocator) that 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 source of > bugs that typically only happened in big and hard to debug inputs so we > moved away from this scheme). > > - Matthias > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160919/80803a0c/attachment.html>
Reasonably Related Threads
- Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
- Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
- Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
- error:Ran out of lanemask bits to represent subregister
- error:Ran out of lanemask bits to represent subregisterr