[llvm-dev] Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 28 08:21:47 PDT 2017
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
More information about the llvm-dev
mailing list