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

[Wei]

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