llvm dev - Nov 2008 - [LLVMdev] Does current LLVM target-independent code generator supports my strange chip?

Hi,
> I am not sure how legalizer and friends deal with i24 / f24 as legal  
> types.
the type legalizer currently assumes that all legal integer types
have a power-of-two number of bits.  I don't see any obstacles to
making it more general though.  First off, i24 would need to be
added to the list of simple value types.  Then the integer promotion
and expansion logic would need to be taught things like this:
i16 promotes to i24, i32 promotes to i48 which is then expanded to
2 x i24.  Finally, all of the code would need to be audited to see
if it assumes that types promoted to / expanded to (or from) are
powers of two in length.  Most of it probably doesn't assume any
such thing, fortunately.

Once types are legal, there's still the problem of making sure
everything else works fine with i24.  One obvious problem is
that (a bit like x86 long double) it isn't naturally aligned.
Presumably if you store two i24's then the second is stored
4 bytes after the first?  Dunno how many places in the code
generator make assumptions about this kind of thing.

Ciao,

Duncan.

O...k... I try to make some conclusions:

1) The conversion from f32 to f24 or i32 to i24 should be written in
the backend.

Because we should not put any hardware dependent behaviors in the
frontend. If we may change our H/W platform to another one which
supports f32, i32 natively, we will only need to change the backend
codes.

For example:
The backend approach means that integer division is a fairly long code
sequence: that's just fine within LLVM.

2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the
problem will be:
  > target independent codegen's legalizer can not handle this.
Because the type legalizer currently assumes that all legal integer
types have a power-of-two number of bits.
  > target independent codegen needs to be taught the i24 type. This
might be a lot of codes. Dunno how to modify LLVM codegen to support
this new type. Is there any document describing this?

Hence, the reasonable approach as far as I know is:

3) Using f32/i32 to represent f24/i24 register, however, the problem
may be:
  > overflow  - Don't know how to solve it in LLVM
  > Does this approach suffer any other drawbacks?

Thanks.
Wei.

On Nov 25, 5:22 pm, Duncan Sands <baldr... at free.fr>
wrote:
> Hi,
>
> > I am not sure how legalizer and friends deal with i24 / f24 as legal  
> > types.
>
> the type legalizer currently assumes that all legal integer types
> have a power-of-two number of bits.  I don't see any obstacles to
> making it more general though.  First off, i24 would need to be
> added to the list of simple value types.  Then the integer promotion
> and expansion logic would need to be taught things like this:
> i16 promotes to i24, i32 promotes to i48 which is then expanded to
> 2 x i24.  Finally, all of the code would need to be audited to see
> if it assumes that types promoted to / expanded to (or from) are
> powers of two in length.  Most of it probably doesn't assume any
> such thing, fortunately.
>
> Once types are legal, there's still the problem of making sure
> everything else works fine with i24.  One obvious problem is
> that (a bit like x86 long double) it isn't naturally aligned.
> Presumably if you store two i24's then the second is stored
> 4 bytes after the first?  Dunno how many places in the code
> generator make assumptions about this kind of thing.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu      
 http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Wednesday 26 November 2008 09:31:26 Wei wrote:
> O...k... I try to make some conclusions:
> 
> 1) The conversion from f32 to f24 or i32 to i24 should be written in
> the backend.
I disagree.  This should be handled by the type legalization
infrastructure.  After all, that's what it is for!  However
there is currently no support for anything like f32 -> f24.
On the other hand, as I mentioned in another email, I think
i32 -> i24 can be done generically.
> 2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the
> problem will be:
>   > target independent codegen's legalizer can not handle this.
> Because the type legalizer currently assumes that all legal integer
> types have a power-of-two number of bits.
If i24 is added as a simple value type, then the type legalizer
can be generalized to handle this without too much difficulty.

Ciao,

Duncan.