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

If this information is useful, please help other people find it:
Share via:

Wei

2008-Nov-22 15:48 UTC

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

Do you mean MVT::getIntegerVT? Because I can not find
getExtendedIntegerVT in the llvm source codes.
I am excited seeing this function, however I have the following more
questions.

1) You mention I will have to change not small amount of target
indenpendent codegen codes to support this extended type.
Are there any document to describe how to do such kind modification?
I see there is a "extending LLVM" document in the official website,
and I don't know whether the info written in its "Adding a new
SelectionDAG node" section (although its quite simple) is what I need?
If not, where can I get more information about this topic?

2) What will go wrong if I use MVT::i32 or MVT::f32 to represent such
a 24-bit register? Will LLVM optimization pass produce wrong codes or
other really bad things? Or just produce codes which will overflow in
some should not overflow situation.

I think I am pretty new in LLVM world. wanna to get more help from you
expert. Thx.

Wei.

On Nov 21, 3:54 pm, Evan Cheng <ech... at apple.com>
wrote:> 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
> > 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

Evan Cheng

2008-Nov-24 19:20 UTC

head link

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

On Nov 22, 2008, at 7:48 AM, Wei wrote:
> Do you mean MVT::getIntegerVT? Because I can not find
> getExtendedIntegerVT in the llvm source codes.
> I am excited seeing this function, however I have the following more
> questions.
See ValueTypes.h and ValueTypes.cpp. Also this example:

@str = internal constant [4 x i8] c"%d\0A\00"

define void @foo2(i24 %a, i24 %b) nounwind {
entry:
  %t1 = add i24 %a, %b
  %t2 = zext i24 %t1 to i32
  %t3 = tail call i32 (i8*, ...)* @printf( i8* getelementptr ([4 x  
i8]* @str, i32 0, i32 0), i32 %t2 ) nounwind
  ret void
}

declare i32 @printf(i8*, ...) nounwind

You can run llc on it to see how codegen deals with i24.
>
>
> 1) You mention I will have to change not small amount of target
> indenpendent codegen codes to support this extended type.
> Are there any document to describe how to do such kind modification?
> I see there is a "extending LLVM" document in the official
website,
> and I don't know whether the info written in its "Adding a new
> SelectionDAG node" section (although its quite simple) is what I need?
> If not, where can I get more information about this topic?
I am not sure how legalizer and friends deal with i24 / f24 as legal  
types.

These are potentially useful.
http://llvm.org/docs/WritingAnLLVMBackend.html
http://llvm.org/docs/CodeGenerator.html

But this is advanced stuff so your best bet is to ask questions here  
(and on irc?).
>
>
> 2) What will go wrong if I use MVT::i32 or MVT::f32 to represent such
> a 24-bit register? Will LLVM optimization pass produce wrong codes or
> other really bad things? Or just produce codes which will overflow in
> some should not overflow situation.
Overflow is going to be a problem. There will probably be more issues  
to work through.

Evan
>
>
> I think I am pretty new in LLVM world. wanna to get more help from you
> expert. Thx.
>
> Wei.
>
> On Nov 21, 3:54 pm, Evan Cheng <ech... at apple.com> wrote:
>> 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
>>> 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

Duncan Sands

2008-Nov-25 09:22 UTC

head link

[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.

Reasonably Related Threads

Search for more apparently analagous threads

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

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

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

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

Reasonably Related Threads