[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register

[Matthias Braun via llvm-dev]

> 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