[LLVMdev] Adding multiples-of-8 integer types to MVT
Micah.Villmow at amd.com
Wed Dec 2 12:45:05 PST 2009
Instead of putting the burden on the back-ends to implement special
lowering code, why not implement code in the legalizer that would
automatically sign extend them to the next largest power of 2 integer if
the specific integer types were not supported. This would then remove
the need of the back-ends to implement anything as LLVM would just
generate extend the values to i32/i64 silently.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Ken Dyck
> Sent: Wednesday, December 02, 2009 12:33 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Adding multiples-of-8 integer types to MVT
> Would there be any interest/opposition to extending the set of simple
> integer types in MVT to include the missing multiples of 8 (up to 64
> bits)? That is: i24, i40, i48, i56?
> Adding the types to MVT (and ValueTypes.td) would allow LLVM to be
> targeted to architectures that have registers and operations of these
> sizes (for example, a 24-bit DSP that I'd like to develop a back end
> has 24-, 48- and 56-bit native integer types). Back ends are currently
> limited to using power-of-2 types in their TableGen descriptions.
> Besides the obvious changes to ValueTypes.h, ValueTypes.td, and
> ValueTypes.cpp, the addition of the new integer types would also
> changing (at least):
> 1. TableGen/CodeGenTarget.cpp - recognize and generate code for the
> 2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the
> legalization of extload and truncstore operations.
> 3. SelectionDAGBuild.cpp - add types to assertsext/assertzext
> in getCopyFromRegs()
> 4. TargetLowering.cpp - eliminate power-of-2 assumptions in
> 5. <Arch>ISelLowering.cpp - specify actions to lower the new types and
> the operations that use them on all existing architectures (ouch!)
> Are there more?
> The main drawback of adding the new types is the extra burden it would
> put on back ends that don't use them, since they would need to add
> special lowering code for all the types they don't use. On the other
> hand, it opens the possibility of targeting architectures that LLVM
> previously couldn't.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev