[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]

  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>