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

Would uint64_t be sufficient for you?

-Krzysztof

On 10/9/2016 12:39 AM, Ruiling Song via llvm-dev wrote: > Hello Alex, >> I am very interested in your change to support more than 32bit lanemask. > I am working on a new llvm backend target which may also needs such kind > of support. > I am not sure whether it is convenient to share the change with me? So I > could have some try. >> Thanks! > Ruiling >> 2016-09-19 5:14 GMT+08:00 Alex Susu via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >> 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 > <https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp>, > comes from the fact there is no IITV128 (nor IITV256), and they is > a switch case using them in method static void > EncodeFixedType(Record R, std::vector &ArgCodes,* > std::vector &Sig). >> Is there any reason these enum IITInfo ( IITV128, IITV256) > 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_ > <mailto:mbraun at apple.com>> wrote: >>> > On Sep 8, 2016, at 6:37 AM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 sub16033". > > > > 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 int1024t from the boost library, header cppint.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 uint32t out of concern > for compiletime. Going up for uint64t 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 >>>>> _ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >>>>> _ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation