[LLVMdev] Adding multiples-of-8 integer types to MVT

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Wed Dec 2 14:10:44 PST 2009


We have plans to implement 24-bit integers on PIC16 in future. So this
addition can help us a lot :)

I was hoping that by only supporting the desired sizes in
<Arch>TargetMachine::DataLayout, different targets would be able to
filter out the unsupported sizes. Besides, these sizes would be there
only if the front end generates them, and that is something that
different targets have control over. If what you say is true, needing to
modify other targets makes the problem more complicated than I
originally thought. 

One more thing that is of concern is that on architectures with such
integer sizes, there may be need for multiple pointer sizes. Currently
LLVM only assumes one size for pointers and that it usually assumed to
be the size of int. This may be another big thing to look at.


Regards
Ali

-----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 1: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 for
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 require
changing (at least):

1. TableGen/CodeGenTarget.cpp - recognize and generate code for the new
types

2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the
legalization of extload and truncstore operations.

3. SelectionDAGBuild.cpp - add types to assertsext/assertzext generation
in getCopyFromRegs()

4. TargetLowering.cpp - eliminate power-of-2 assumptions in
computeRegisterProperties()

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. 

Thoughts?

Regards,
-Ken


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list