[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
llvm-dev at lists.llvm.org
Tue Aug 1 04:47:16 PDT 2017
Hello.
Is it part of the LLVM developer policy NOT to use the Boost library (for the
TableGen and llc tools, etc)?
I see some people use sometimes Boost with LLVM:
https://caesr.uwaterloo.ca/misc/boost-llvm-clang.html, also
http://lists.llvm.org/pipermail/llvm-dev/2012-October/054873.html .
Thank you,
Alex
On 7/28/2017 6:21 PM, Krzysztof Parzyszek via llvm-dev wrote:
> 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
>
More information about the llvm-dev
mailing list