llvm dev - Aug 2012 - [LLVMdev] Passing return values on the stack & storing arbitrary sized integers

Hi Eli,

thank you for the information.
>> thanks to kind help of the LLVM-community I was able to bring my
>> TriCore back-end a huge step forward, however I am not done, so far. I
>> still miss the following features and maybe you could again provide me
>> some help:
>>
>> 1. Passing return values on the stack
>>
>> Describing the calling conventions in tablegen so that first registers
>> are used and to fall back to the stack if these do not suffice.
>> However, this is not enough and lowering calls and returns have to
>> reflect this, too.  Currently, most targets also do not support this
>> (there is assertion: assert(VA.isRegLoc() && "Can only
return in
>> registers!")).
>>
>> How important is this feature? Is it save to ignore it? Is there some
>> guide how to implement such a hybrid passing of return values (partly
>> in registers, partly on the stack)? Currently, the TriCore back-end is
>> not able to compile functions returning e.g. {i128,i1}.
>
> This isn't very important; you won't run into it compiling C code.
OK, fine :-)
>> 2. Storing arbitrary sized integers
>>
>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks
for
>> loading/storing e.g. i33 integers from/into global variable. The
>> questions are the same as regarding feature 1: How important is this
>> feature? Is it save to ignore it? Is there some guide how to implement
>> this?
>
> If you're using the LLVM CodeGen infrastructure and have everything
> else implemented correctly, this should be taken care of for you.  We
> have infrastructure generally referred to as "legalization" that
will
> transform this into something sane for your target automatically.  I
> would suggest not ignoring this because the optimizers will
> occasionally generate unusual loads and stores.
Hm, my problem is that the TriCore does not really support i64 only
paired 32.bit registers, but I need such a register class as some
instructions require them. So, the Legalizer thinks i64-instructions
are legal and integer types above i32 are not legalized automatically.
For the most operations I used setOperationAction, setLoadExtAction,
... and now I have to handle loads/stores for i33. Maybe you can guide
me, where I shall look at inside LLVM how to do that.

Ciao, Fabian

On Thu, Aug 16, 2012 at 11:48 PM, Fabian Scheler
<fabian.scheler at gmail.com> wrote:
> Hi Eli,
>
> thank you for the information.
>
>>> thanks to kind help of the LLVM-community I was able to bring my
>>> TriCore back-end a huge step forward, however I am not done, so
far. I
>>> still miss the following features and maybe you could again provide
me
>>> some help:
>>>
>>> 1. Passing return values on the stack
>>>
>>> Describing the calling conventions in tablegen so that first
registers
>>> are used and to fall back to the stack if these do not suffice.
>>> However, this is not enough and lowering calls and returns have to
>>> reflect this, too.  Currently, most targets also do not support
this
>>> (there is assertion: assert(VA.isRegLoc() && "Can only
return in
>>> registers!")).
>>>
>>> How important is this feature? Is it save to ignore it? Is there
some
>>> guide how to implement such a hybrid passing of return values
(partly
>>> in registers, partly on the stack)? Currently, the TriCore back-end
is
>>> not able to compile functions returning e.g. {i128,i1}.
>>
>> This isn't very important; you won't run into it compiling C
code.
>
> OK, fine :-)
>
>>> 2. Storing arbitrary sized integers
>>>
>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll"
checks for
>>> loading/storing e.g. i33 integers from/into global variable. The
>>> questions are the same as regarding feature 1: How important is
this
>>> feature? Is it save to ignore it? Is there some guide how to
implement
>>> this?
>>
>> If you're using the LLVM CodeGen infrastructure and have everything
>> else implemented correctly, this should be taken care of for you.  We
>> have infrastructure generally referred to as "legalization"
that will
>> transform this into something sane for your target automatically.  I
>> would suggest not ignoring this because the optimizers will
>> occasionally generate unusual loads and stores.
>
> Hm, my problem is that the TriCore does not really support i64 only
> paired 32.bit registers, but I need such a register class as some
> instructions require them. So, the Legalizer thinks i64-instructions
> are legal and integer types above i32 are not legalized automatically.
> For the most operations I used setOperationAction, setLoadExtAction,
> ... and now I have to handle loads/stores for i33. Maybe you can guide
> me, where I shall look at inside LLVM how to do that.
I'm not entirely sure why, but this seems to be a very frequent
mistake: don't mark i64 legal unless you actually have i64 registers.
Lying to the legalizer creates extra work for your target, and you're
using codepaths which aren't well tested.  There are better ways to
model a pair of i32 registers; if you have some case you're having
trouble modeling, please ask.

-Eli

Hi Eli,
>>>> 2. Storing arbitrary sized integers
>>>>
>>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll"
checks for
>>>> loading/storing e.g. i33 integers from/into global variable.
The
>>>> questions are the same as regarding feature 1: How important is
this
>>>> feature? Is it save to ignore it? Is there some guide how to
implement
>>>> this?
>>>
>>> If you're using the LLVM CodeGen infrastructure and have
everything
>>> else implemented correctly, this should be taken care of for you. 
We
>>> have infrastructure generally referred to as
"legalization" that will
>>> transform this into something sane for your target automatically. 
I
>>> would suggest not ignoring this because the optimizers will
>>> occasionally generate unusual loads and stores.
>>
>> Hm, my problem is that the TriCore does not really support i64 only
>> paired 32.bit registers, but I need such a register class as some
>> instructions require them. So, the Legalizer thinks i64-instructions
>> are legal and integer types above i32 are not legalized automatically.
>> For the most operations I used setOperationAction, setLoadExtAction,
>> ... and now I have to handle loads/stores for i33. Maybe you can guide
>> me, where I shall look at inside LLVM how to do that.
>
> I'm not entirely sure why, but this seems to be a very frequent
> mistake: don't mark i64 legal unless you actually have i64 registers.
> Lying to the legalizer creates extra work for your target, and you're
> using codepaths which aren't well tested.  There are better ways to
> model a pair of i32 registers; if you have some case you're having
> trouble modeling, please ask.
well, I did not implement the back-end at first, I am currently only
adapting it to LLVM 3.1, so I don't know if it was possible to model
the TriCore ISA in a better way. The TriCore supports register pairs
of two adjacent (even,odd) registers forming one 64-bit registers. A
few operation of the TriCore exploit these register pairs:
multiplication, for instance, places its result in on of those
register pairs, it it possible to load/store such register pairs
directly from/to memory and the calling conventions take them into
account, too. Everything else has to be done using 32-bit registers
and instructions.

In the first place, these registers pairs were only present in the
tablegen descriptions and were only used to define the
multiplication-instruction. Furthermore, the calling conventions were
tweaked to be compatible to those specified by the TriCore EABI
(64-bit arguments have to passed in an appropriate register pair).
Everything worked quite fine. When moving to LLVM 3.1, however, the
generic code generation framework complained that it knew nothing
about those registers pairs that were only described in tablegen when
selecting the multiplication-instruction. So, I found no other
solution than to add these register pairs as i64-registers.

If there is a more convenient solution for this setup, I would be
really glad to learn about it :-)

Ciao, Fabian