[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
Alex Susu via llvm-dev
llvm-dev at lists.llvm.org
Sun Sep 18 14:14:29 PDT 2016
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
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?
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
> > 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
> 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...
More information about the llvm-dev