[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
Ruiling Song via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 13 00:29:54 PDT 2016
Hi Krzysztof,
uint64_t is not enough for me. seems that 128bit is enough for me.
what I am doing is like I need to define the register set for 16 working
threads in a warp in nvidia terminology. I often call the 'warp size' as
simd-width.
Like AMDGPU, the arch support scalar/vector register. the vector width is
16 if the simd-width/warp-size is 16.
But the scalar/vector register reside in only one register file, so they
need to alias each other. That is a vector register can also be used as
several scalar registers.
What I choose to do is define scalar 'short' type register, and a vector
register for QWord is composed of 16(simd-width)*4(size in unit of short) =
64 uniform short register.
So, for normal usage under simd-width of 16, 64bit lane mask is enough.
The problem is the 'store' or 'load' operation can support up to SIMD16 of
4 DWord read/write. And the arch requires the four element register in
consecutive registers.
So I have to define a registerTuple that is composed of 16(simd-width) *
4(element) * 2(size in units of short) = 128 uniform short register. That
means 128 bits lanemask.
Some previous discussion threads if you are interested:
http://lists.llvm.org/pipermail/llvm-dev/2016-August/103953.html
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104772.html
Thanks!
Ruiling
2016-10-10 23:20 GMT+08:00 Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org>:
> 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/TableG
>> en/IntrinsicEmitter.cpp
>> <https://github.com/llvm-mirror/llvm/blob/master/utils/Table
>> Gen/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
>> <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 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/0d5344e7/attachment.html>
More information about the llvm-dev
mailing list