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

[Wei]

Daniel,

Many thanks for your recommendations.
I think your method is an easiest way to handle this situation without
modify LLVM itself.
Thanks for your recommendations again.

Wei.

On Nov 26, 11:35 pm, Daniel M Gessel <ges... at apple.com> wrote:
> I think Duncan and I disagree. Generally I would defer to anybody else  
> on this list: my experience is backend Target only, with very little  
> poking around the internals. I'm usually asking, not answering,  
> questions here: the 24 bit floats reminded me of the "good old days"  
> at ATI.
>
> That said, I think you could make f32/i32 work for your purposes -  
> given the limited types and memory operations of unextended GLSL. At a  
> minimum, I think that starting with f32/i32 would give you chance to  
> learn and understand more about LLVM.
>
> If there are people who are willing to help you add i24/f24 to LLVM's  
> core code base or you have time to learn about LLVM's internals on  
> your own, then adding 24 bit support seems the safer path (if only  
> because it is recommended by people more knowledgeable than myself).
>
> Dan
>
> On Nov 26, 2008, at 4:38 AM, Wei wrote:
>
>
>
> >> I disagree.  This should be handled by the type legalization
> >> infrastructure.
>
> > huh...
> > As far as I know, the type legalization is in the SelectionDAG phase,
> > and it is also in the backend. Am I right? or I miss something.
>
> >> there is currently no support for anything like f32 -> f24
>
> > You say "there is currently no support for anything like f32 -> f24",
> > does it means I can not write codes like below?
>
> > addRegisterClass(MVT::i24, XXXRegisterClass);
>
> > If the target-indenpendent codegen supports i24, then I can writes
> > codes like above, then does it means LLVM backend codegen can handle
> > any i32->i24 and f32->f24 for me automatically? So that I don't need
> > to worry about i32->i24 and f32->f24?
>
> >> On the other hand, as I mentioned in another email, I think
> >> i32 -> i24 can be done generically.
>
> > I don't think I got you here...
> > You mean using the legalizer to handle this for me? or modify the
> > target independent codegen to let it know i24?
>
> > Thanks.
> > Wei.
>
> > On Nov 26, 5:07 pm, Duncan Sands <baldr... at free.fr> wrote:
> >> 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.
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVM... at cs.uiuc.edu        http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVM... at cs.uiuc.edu        http://llvm.cs.uiuc.edu
> >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu        http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev