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

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.

> 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

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
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev