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

Hello.
     I managed to use SIMD units with more than 32 lanes (32 subregisters per
vector
register) in TableGen, llc and opt. For example, I use SIMD instructions with
types
v128i16 and v512i16.

     An important questions I have is if it is OK to add the types IIT_V128 =
37, IIT_V256
= 38 like I did below:
         enum IIT_Info {
           ...
           IIT_V2   = 9,
           IIT_V4   = 10,
           IIT_V8   = 11,
           IIT_V16  = 12,
           IIT_V32  = 13,
           ...
           IIT_V64  = 16,
           IIT_V1   = 28,
           IIT_VEC_OF_PTRS_TO_ELT = 33,
           IIT_V512 = 35,
           IIT_V1024 = 36,

           /* Alex: added these new values. Note that these IIT_* that I add
below must be
defined in llvm.org/docs/doxygen/html/Function_8cpp.html also */
           IIT_V128 = 37,
           IIT_V256 = 38
         };

     I ask because enum IIT_Info has some values that are not consecutive for
vector types
for intrinsics (used e.g. in include/llvm/IR/Intriniscs*.td).
     Although not important, I wonder why do I still need to define them again
(since
these values are basically already defined in ValueTypes.td) ?


     So, I managed to get the code compiled. I had issues because I did not
synchronize
the following code:
       - enum IIT_Info defined in files llvm/utils/TableGen/IntrinsicEmitter.cpp
and
llvm/lib/IR/Function.cpp;
       - enum SympleValueType defined in files
llvm/include/llvm/CodeGen/ValueTypes.td and
llvm/include/llvm/CodeGen/MachineValueType.h .
     I was getting errors because of this out-of-sync like:
       - "error:unhandled vector type width in intrinsic!",
"error:unhandled MVT in
intrinsic!"
       - "Not a vector MVT!", "getSizeInBits called on extended
MVT."


   Best regards,
     Alex

On 9/19/2016 12:14 AM, Alex Susu wrote:
>   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
> <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
>
>
>

You seem to be using old LLVM sources---changing this many files for 
supporting a different width LaneBitmask is no longer necessary.

Also, boost is not a current requirement for building LLVM and it's 
unlikely that requiring it for that purpose alone is justified.

-Krzysztof


On 7/28/2017 6:30 AM, Alex Susu via llvm-dev wrote:
>    Hello.
>      I come back to this older thread.
> 
>      As I've said before, I managed to patch the various files from the
> back end related to lanemask in order to support at most 1024 vector 
> lanes. For this I am using a 1024-bit long lanemask of type uint1024_t 
> from boost::multiprecision, instead of uint32_t. For this I changed the 
> following LLVM source files:
>        [repository]/llvm/utils/TableGen/CodeGenRegisters.cpp
>        [repository]/llvm/utils/TableGen/CodeGenRegisters.h
>        [repository]/llvm/utils/TableGen/RegisterInfoEmitter.cpp
>        [repository]/llvm/lib/CodeGen/TargetRegisterInfo.cpp
>        [repository]/llvm/lib/CodeGen/MachineVerifier.cpp
>        [repository]/llvm/include/llvm/Target/TargetRegisterInfo.h
>        [repository]/llvm/include/llvm/MC/MCRegisterInfo.h
>        [repository]/llvm/include/llvm/CodeGen/MachineBasicBlock.h
>        [repository]/llvm/include/llvm/CodeGen/RegisterPressure.h
>      I plan to contribute patches for these changes to the llvm-commits 
> mailing list.
>      These changes were tested by me for more than 6 months with llc on 
> various benchmarks - things seem to work well.
> 
>      Besides these changes I added new vector types (basically all 
> vector types that were not already present in LLVM, from 32 lanes to 
> 1024, for types i8, i16, i32, i64 and f16/32/64, etc - examples of types 
> that I needed are v128i1, v128i16, also v1024f64). The files I changed are:
>        [repository]/llvm/include/llvm/CodeGen/ValueTypes.td
>        [repository]/lib/IR/ValueTypes.cpp
>        [repository]/include/llvm/IR/Intrinsics.td
>        [repository]/llvm/include/llvm/CodeGen/MachineValueType.h
>        [repository]/llvm/utils/TableGen/CodeGenTarget.cpp
>      Please let me know if you want to commit these changes also - they 
> are rather complex in the sense there are a lot of small dependencies 
> for these types.
> 
>    Best regards,
>      Alex
> 
> 
> On 9/20/2016 12:48 PM, Alex Susu wrote:
>>   Hello.
>>     I managed to use SIMD units with more than 32 lanes (32 
>> subregisters per vector
>> register) in TableGen, llc and opt. For example, I use SIMD 
>> instructions with types
>> v128i16 and v512i16.
>>
>>     An important questions I have is if it is OK to add the types 
>> IIT_V128 = 37, IIT_V256
>> = 38 like I did below:
>>         enum IIT_Info {
>>           ...
>>           IIT_V2   = 9,
>>           IIT_V4   = 10,
>>           IIT_V8   = 11,
>>           IIT_V16  = 12,
>>           IIT_V32  = 13,
>>           ...
>>           IIT_V64  = 16,
>>           IIT_V1   = 28,
>>           IIT_VEC_OF_PTRS_TO_ELT = 33,
>>           IIT_V512 = 35,
>>           IIT_V1024 = 36,
>>
>>           /* Alex: added these new values. Note that these IIT_* that 
>> I add below must be
>> defined in llvm.org/docs/doxygen/html/Function_8cpp.html also */
>>           IIT_V128 = 37,
>>           IIT_V256 = 38
>>         };
>>
>>     I ask because enum IIT_Info has some values that are not 
>> consecutive for vector types
>> for intrinsics (used e.g. in include/llvm/IR/Intriniscs*.td).
>>     Although not important, I wonder why do I still need to define 
>> them again (since these
>> values are basically already defined in ValueTypes.td) ?
>>
>>
>>     So, I managed to get the code compiled. I had issues because I did 
>> not synchronize the
>> following code:
>>       - enum IIT_Info defined in files 
>> llvm/utils/TableGen/IntrinsicEmitter.cpp and
>> llvm/lib/IR/Function.cpp;
>>       - enum SympleValueType defined in files 
>> llvm/include/llvm/CodeGen/ValueTypes.td and
>> llvm/include/llvm/CodeGen/MachineValueType.h .
>>     I was getting errors because of this out-of-sync like:
>>       - "error:unhandled vector type width in intrinsic!", 
>> "error:unhandled MVT in
>> intrinsic!"
>>       - "Not a vector MVT!", "getSizeInBits called on
extended MVT."
>>
>>
>>   Best regards,
>>     Alex
>>
>> On 9/19/2016 12:14 AM, Alex Susu wrote:
>>>   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
>>> <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
> 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