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 |
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 > 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
---------- 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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |