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

Thu Nov 20 23:54:26 PST 2008

24 bit is not unusual in the DSP world. I suppose int == 24 bit  
integer for some of these chips?

There isn't a i24 simple type. However, you can create an extended  
integer type. See getExtendedIntegerVT. It's almost guaranteed you  
will have to change a chunk of target independent codegen to support  
the use of an extended type though.

Evan

On Nov 20, 2008, at 4:46 AM, Wei wrote:

> Because each channel contains 24-bit, so.. what is the
> llvm::SimpleValueType I should use for each channel?
> the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32,
> f64, f80, none of them are fit one channel (24-bit).
>
> I think I can use i32 or f32 to represent each 24-bit channel, if the
> runtime result of some machine instructions exceeds 23-bit (1 bit is
> for sign), then it is an overflow.
> Is it correct to claim that the programmers needs to revise his
> program to fix this problem?
> Am I right or wrong about this thought?
>
> If there is a chip, whose registers are 24-bit long, and you have to
> compile C/C++ programs on it.
> How would you represent the following statement?
>
> int a = 3;
> (Programmers think sizeof(int) = 4)
>
> Wei.
>
> On Nov 19, 2:01 am, Evan Cheng <evan.ch... at apple.com> wrote:
>> Why not model each channel as a separate physical register?
>>
>> Evan
>>
>> On Nov 17, 2008, at 6:36 AM, Wei wrote:
>>
>>> I have a very strange and complicate H/W platform.
>>> It has many registers in one format.
>>> The register format is:
>>
>>> ------------------------------
>>> ----------------------------------------------------------------------------------------
>>> |         24-bit                |             24-bit
>>> |           24-bit               |              24-bit            |
>>> ----------------------------------------------------------------------------------------------------------------------
>>>               a
>>> b
>>> c                                       d
>>
>>> There are 4 channels in a register, and each channel contains 24-
>>> bit, hence, there are total 96-bit in 'one' register.
>>> You can store a 24-bit integer or a s7.16 floating-point data into
>>> each channel.
>>> You can name each channel 'a', 'b', 'c', 'd'.
>>
>>> Here is an example of the operation in this H/W platform:
>>
>>>             ADD      R3.ab, R1.abab, R2.bbaa
>>
>>> it means
>>
>>>            Add 'abab' channel of R1 and 'bbaa' channel of R2, and
>>> put the result into the 'ab' channel of R3.
>>
>>> It's complicate.
>>> Imagine a non-existed temp register named 'Rt1', the content of its
>>> 'a','b','c','d' channel are got from 'a','b','a','b' channel of R1,
>>> and imagine another non-existed temp register named 'Rt2', the
>>> content of its 'a','b','c','d' channel are got from 'b','b','a','a'
>>> channel of R2.
>>> and then add Rt1 & Rt2, put the result to R3
>>> this means
>>> the 'a' channel of R3 will be equal to the 'a' channel of Rt1 plus
>>> the 'a' channel of Rt2, (i.e. 'a' from R1 + 'b' from R2, because
>>> R1.'a'bab and R2.'b'baa)
>>> the 'b' channel of R3 will be equal to the 'b' channel of Rt1 plus
>>> the 'b' channel of Rt2, (i.e. 'b' from R1 + 'b' from R2, because
>>> R1.a'b'ab and R2.b'b'aa)
>>> the 'c' channel of R3 will be untouched, the value of the 'c'
>>> channel of Rt1 plus the 'c' channel of Rt2 (i.e. 'a' from R1 + 'a'
>>> from R2, because R1.ab'a'b and R2.bb'a'a) will be lost.
>>> the 'd' channel of R3 will be untouched, too. The value of the 'd'
>>> channel of Rt1 plus the 'd' channel of Rt2 (i.e. 'b' from R1 + 'a'
>>> from R2, because R1.aba'b' and R2.bba'a') will be lost, too.
>>
>>> I don't know whether I can set the 'type' of such register using a
>>> llvm::MVT::SimpleValueType?
>>> According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8,
>>> v2f32, etc is used to represent register for SIMD instructions.
>>> I don't think the operations in my platform are SIMD instructions.
>>> However, I can not find any llvm::MVT::SimpleValueType which can
>>> represents a 96-bit register.
>>
>>> Thus, my question is:
>>
>>> 1) Does current LLVM backend supports this H/W?
>>> 2) If yes, how can I write the type of the register class in my .td
>>> file?
>>
>>> (Which value should I fill in the following 'XXX' ?)
>>> def TempRegs : RegisterClass<"MFLEXG", [XXX], 32, [R0, R1, R2, R3,
>>> R4, R5, R6, R7, R8, R9,
>>>                                                    R10, R11, R12,
>>> R13, R14, R15, R16, R17, R18, R19,
>>>                                                    R20, R21, R22,
>>> R23, R24, R25, R26, R27, R28, R29,
>>>                                                    R30, R31]> {
>>> }
>>
>>> 3) If not, does this means I have to write the whole LLVM backend
>>> based on the basic llvm::TargetMachine & llvm::TargetData, just like
>>> what CBackend does?
>>
>>> --------------------------------------------------------
>>> Wei Hu
>>> http://www.csie.ntu.edu.tw/~r88052/
>>> http://wei-hu-tw.blogspot.com/
>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev