Adding multiples-of-8 integer types to MVT

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding multiples-of-8 integer types to MVT

Ken Dyck-2
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Villmow, Micah
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.

Micah

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Ken Dyck
> Sent: Wednesday, December 02, 2009 12:33 PM
> To: [hidden email]
> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Alireza.Moshtaghi
In reply to this post by Ken Dyck-2
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: [hidden email] [mailto:[hidden email]]
On Behalf Of Ken Dyck
Sent: Wednesday, December 02, 2009 1:33 PM
To: [hidden email]
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Chris Lattner-2
In reply to this post by Ken Dyck-2

On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote:

> 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.

I'm fine with doing this, but please only add the MVT types you  
actually need.  Don't bother adding i40 unless you support i40.  If  
someone needs it in the future, we can add it at that point.

Thanks Ken,

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Duncan Sands
In reply to this post by Ken Dyck-2
Hi Ken,

> 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?

the type legalizer would need some work.  Consider an architecture which has a
24 bit register.  Then the type legalizer should legalize an i40 by first
promoting it to an i48, then expanding that to two lots of i24.

Another issue is how vectors of i24 would be represented in memory.  Would
successive vector elements be 3 bytes apart or 4 bytes apart?  The current
code for vector codegen assumes that vectors are tightly packed (this is
already wrong for x86 long double).

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Ken Dyck-2
In reply to this post by Villmow, Micah
On Wednesday, December 02, 2009 3:45 PM, Micah Villmow wrote:

>
> On Wednesday, December 02, 2009 12:33 PM, Ken Dyck wrote:
>
> > 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.
>
> 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.

I agree. It would be ideal to limit the changes to the legalizer. I've
been working on this in a private branch for a little while and so far I
haven't figured out a way to make it work. I'm fairly new to LLVM,
though, so there's a good chance my failure is due to a personal lack of
understanding rather than some fundamental technical issue. I'll keep
working on it.  

-Ken


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Ken Dyck-2
In reply to this post by Chris Lattner-2
On Wednesday, December 02, 2009 7:09 PM, Chris Lattner wrote:

>
> On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote:
>
> > 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.
>
> I'm fine with doing this, but please only add the MVT types
> you actually need.  Don't bother adding i40 unless you
> support i40.  If someone needs it in the future, we can add
> it at that point.

Judging from a comment near the end of BlackfinRegisterInfo.td, it looks
like the Blackfin back end could make use i40. Would you still like it
left out?

-Ken

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Duncan Sands
In reply to this post by Ken Dyck-2
>> 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.
>
> I agree. It would be ideal to limit the changes to the legalizer. I've
> been working on this in a private branch for a little while and so far I
> haven't figured out a way to make it work. I'm fairly new to LLVM,
> though, so there's a good chance my failure is due to a personal lack of
> understanding rather than some fundamental technical issue. I'll keep
> working on it.  

I also agree that the type legalizer is the place to take care of it.
This would be straightforward for someone who has experience with the
type legalizer - the problem is finding someone with some spare time!

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Chris Lattner-2
In reply to this post by Ken Dyck-2

On Dec 3, 2009, at 4:28 AM, Ken Dyck wrote:

>>
>> I'm fine with doing this, but please only add the MVT types
>> you actually need.  Don't bother adding i40 unless you
>> support i40.  If someone needs it in the future, we can add
>> it at that point.
>
> Judging from a comment near the end of BlackfinRegisterInfo.td, it  
> looks
> like the Blackfin back end could make use i40. Would you still like it
> left out?

I'd prefer to leave it out.  When the blackfin backend needs it, it  
should be easy to add then.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Ken Dyck-2
In reply to this post by Duncan Sands
On Thursday, December 03, 2009 3:52 AM, Duncan Sands wrote:

>
> > 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?
>
> the type legalizer would need some work.  Consider an
> architecture which has a
> 24 bit register.  Then the type legalizer should legalize an
> i40 by first promoting it to an i48, then expanding that to
> two lots of i24.

>From what I can tell, this is mostly a matter of making sure that the
lowering tables in TargetLowering are initialized correctly in
computeRegisterProperties(). The rest of it is finding the code that are
bypassing these lowering tables to legalize types.
 
> Another issue is how vectors of i24 would be represented in
> memory.  Would successive vector elements be 3 bytes apart or
> 4 bytes apart?  The current code for vector codegen assumes
> that vectors are tightly packed (this is already wrong for
> x86 long double).

FWIW, I would hope they continue to be packed. Otherwise, they would be
very difficult to process efficiently on native 24-bit machines. On
architectures without 24-bit types, I guess it would be up to the
legalizer to generate code to pad them appropriately in a promotion to
an i32 vector.

-Ken

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Duncan Sands-2
In reply to this post by Duncan Sands
>> 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?

By the way, the integer type legalization logic should probably go like
this: let T be an integer type.

(1) If T is legal, do nothing.
(2) If there is a legal integer type which is bigger (in bitwidth) than T,
then promote T to the smallest legal type which is bigger than T.
(3) In the remaining case, T is necessarily bigger than the largest legal
integer type (call this type L).  Take the smallest positive N such that
  (bitwidth of T) <= (bitwidth of L) * 2^N
If you have equality in the equation, i.e. if the bitwidth of T is a power
of two multiple of the bitwidth of L, then expand T into two equal integer
types of half the size.  Otherwise promote T to the type with bitwidth equal
to the right-hand-side of the equation, i.e. (bitwidth of L) * 2^N.

If all legal integer types have a power of two size, then this coincides
with what we have today.  If some legal types do not have a power of 2
size then finding the type to promote to in (2) requires more computation
than in the power-of-two case.  For (3), you need to know the largest legal
type L, which currently isn't exposed in a convenient way for this.  For
simple integer types everything can of course be pre-calculated in tables,
like now.  For extended integer types it would be good to have an efficient
algorithm for calculating this on the fly.  At worst, values can be cached.

Ciao,

Duncan.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Fwd: Adding multiples-of-8 integer types to MVT

Bugzilla from overminddl1@gmail.com
Grr...


---------- Forwarded message ----------
From: OvermindDL1 <[hidden email]>
Date: Sat, Dec 5, 2009 at 5:58 PM
Subject: Re: [LLVMdev] Adding multiples-of-8 integer types to MVT
To: Duncan Sands <[hidden email]>


On Sat, Dec 5, 2009 at 5:33 AM, Duncan Sands
<[hidden email]> wrote:

>>> 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?
>
> By the way, the integer type legalization logic should probably go like
> this: let T be an integer type.
>
> (1) If T is legal, do nothing.
> (2) If there is a legal integer type which is bigger (in bitwidth) than T,
> then promote T to the smallest legal type which is bigger than T.
> (3) In the remaining case, T is necessarily bigger than the largest legal
> integer type (call this type L).  Take the smallest positive N such that
>  (bitwidth of T) <= (bitwidth of L) * 2^N
> If you have equality in the equation, i.e. if the bitwidth of T is a power
> of two multiple of the bitwidth of L, then expand T into two equal integer
> types of half the size.  Otherwise promote T to the type with bitwidth equal
> to the right-hand-side of the equation, i.e. (bitwidth of L) * 2^N.
>
> If all legal integer types have a power of two size, then this coincides
> with what we have today.  If some legal types do not have a power of 2
> size then finding the type to promote to in (2) requires more computation
> than in the power-of-two case.  For (3), you need to know the largest legal
> type L, which currently isn't exposed in a convenient way for this.  For
> simple integer types everything can of course be pre-calculated in tables,
> like now.  For extended integer types it would be good to have an efficient
> algorithm for calculating this on the fly.  At worst, values can be cached.

This makes the most sense to me as well.  I have used some embedded
chips (long time ago, but still...) that had a 7-bit wide bus and
register setup, certainly not a power of 2, not even even.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Adding multiples-of-8 integer types to MVT

Hongbin Zheng
ya, when you targeting some backend like FPGA, you are able to meet a
integer with any bitwitdh.

On Sun, Dec 6, 2009 at 8:58 AM, OvermindDL1 <[hidden email]> wrote:

> Grr...
>
>
> ---------- Forwarded message ----------
> From: OvermindDL1 <[hidden email]>
> Date: Sat, Dec 5, 2009 at 5:58 PM
> Subject: Re: [LLVMdev] Adding multiples-of-8 integer types to MVT
> To: Duncan Sands <[hidden email]>
>
>
> On Sat, Dec 5, 2009 at 5:33 AM, Duncan Sands
> <[hidden email]> wrote:
>>>> 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?
>>
>> By the way, the integer type legalization logic should probably go like
>> this: let T be an integer type.
>>
>> (1) If T is legal, do nothing.
>> (2) If there is a legal integer type which is bigger (in bitwidth) than T,
>> then promote T to the smallest legal type which is bigger than T.
>> (3) In the remaining case, T is necessarily bigger than the largest legal
>> integer type (call this type L).  Take the smallest positive N such that
>>  (bitwidth of T) <= (bitwidth of L) * 2^N
>> If you have equality in the equation, i.e. if the bitwidth of T is a power
>> of two multiple of the bitwidth of L, then expand T into two equal integer
>> types of half the size.  Otherwise promote T to the type with bitwidth equal
>> to the right-hand-side of the equation, i.e. (bitwidth of L) * 2^N.
>>
>> If all legal integer types have a power of two size, then this coincides
>> with what we have today.  If some legal types do not have a power of 2
>> size then finding the type to promote to in (2) requires more computation
>> than in the power-of-two case.  For (3), you need to know the largest legal
>> type L, which currently isn't exposed in a convenient way for this.  For
>> simple integer types everything can of course be pre-calculated in tables,
>> like now.  For extended integer types it would be good to have an efficient
>> algorithm for calculating this on the fly.  At worst, values can be cached.
>
> This makes the most sense to me as well.  I have used some embedded
> chips (long time ago, but still...) that had a 7-bit wide bus and
> register setup, certainly not a power of 2, not even even.
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Fwd: Fwd: Adding multiples-of-8 integer types to MVT

Bugzilla from overminddl1@gmail.com
---------- Forwarded message ----------
From: OvermindDL1 <[hidden email]>
Date: Sat, Dec 5, 2009 at 8:12 PM
Subject: Re: [LLVMdev] Fwd: Adding multiples-of-8 integer types to MVT
To: ether zhhb <[hidden email]>


On Sat, Dec 5, 2009 at 7:24 PM, ether zhhb <[hidden email]> wrote:
> ya, when you targeting some backend like FPGA, you are able to meet a
> integer with any bitwitdh.

That is a *very* good point.  Since most FPGA boards are configurable
right down to the bitwidth of the lines, any possible bitwidth could
possibly exist.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Ken Dyck-2
In reply to this post by Duncan Sands-2
On Saturday, December 05, 2009 7:34 AM, Duncan Sands wrote,

>
> >> 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?
>
> By the way, the integer type legalization logic should
> probably go like
> this: let T be an integer type.
>
> (1) If T is legal, do nothing.
> (2) If there is a legal integer type which is bigger (in
> bitwidth) than T, then promote T to the smallest legal type
> which is bigger than T.
> (3) In the remaining case, T is necessarily bigger than the
> largest legal integer type (call this type L).  Take the
> smallest positive N such that
>   (bitwidth of T) <= (bitwidth of L) * 2^N If you have
> equality in the equation, i.e. if the bitwidth of T is a
> power of two multiple of the bitwidth of L, then expand T
> into two equal integer types of half the size.  Otherwise
> promote T to the type with bitwidth equal to the
> right-hand-side of the equation, i.e. (bitwidth of L) * 2^N.


What would do you think of modifying case (3) slightly as follows?

(3) In the remaining case, T is necessarily bigger than the largest
legal integer type (call this type L).  Take the smallest positive N
such that for some legal type, Leg,
 
  (bitwidth of T) <= (bitwidth of Leg) * 2^N

Of the types that satisfy this relation, call the smallest S. If you
have equality in the equation when Leg:=S, i.e. if the bitwidth of T is
a power of two multiple of the bitwidth of the smallest legal type to
which it can be expanded, then expand T into two equal integer types of
half the size.  Otherwise promote T to the type with bitwidth equal to
the right-hand-side of the equation, i.e. (bitwidth of S) * 2^N.

On a target with 32- and 24-bit registers, for example, this
modification would allow i48 to be expanded directly to 24-bit registers
instead of promoting to an i64 and expanding to 32-bit.

-Ken

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Duncan Sands
Hi Ken,

> What would do you think of modifying case (3) slightly as follows?

well, that special cases the smallest legal type, which might not be
a good idea.  Imagine that i10 is legal, and also i32.  Is it better
to turn i40 into four lots of i10 or two lots of i32 with a promotion?
Expansion is expensive, so two lots of i32 would be best.  I suggest the
following scheme:

(3) Suppose T is larger than the largest legal type.  Look at all the
legal types LT for which
   bitwidth T <= 2 * bitwidth of LT
If there is one, take the smallest one (SLT) and promote T to 2*SLT.
If there are none (because bitwidth T is too big), look at all the
legal types LT for which
   bitwidth T <= 4 * bitwidth of LT
If there is one, take the smallest one (SLT) and promote T to 4*SLT.
Continue with 8*, 16* etc.

For example, if i24 and i32 are the legal types, with this algorithm
types i33, ..., i48 would be promoted to i48 then expanded to two lots
of i24.  Types i49, ..., i64 would be promoted to i64 then expanded to
two lots of i32.

For example, if i10 and i32 are the legal types, i40 would be promoted
to i64 then expanded to two lots of i32.

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Adding multiples-of-8 integer types to MVT

Ken Dyck-2
 

On Saturday, December 12, 2009 2:43 AM, Duncan Sands wrote:

>
> > What would do you think of modifying case (3) slightly as follows?
>
> I suggest the following scheme:
>
> (3) Suppose T is larger than the largest legal type.  Look at
> all the legal types LT for which
>    bitwidth T <= 2 * bitwidth of LT
> If there is one, take the smallest one (SLT) and promote T to 2*SLT.
> If there are none (because bitwidth T is too big), look at
> all the legal types LT for which
>    bitwidth T <= 4 * bitwidth of LT
> If there is one, take the smallest one (SLT) and promote T to 4*SLT.
> Continue with 8*, 16* etc.

This is actually exactly what I was proposing. Apparently I didn't
express it clearly enough, though. I'm glad to see that we agree,
anyways.

-Ken

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev