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

Hi everybody,

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

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?

When looking for some kind of guide, I am not looking for step-by-step
instructions to implement these issues, but a well documented back-end
would be really helpful, here. While being the most complete target,
the X86 target IMO is much too complex for that purpose.

BTW: are the testcases in test/CodeGen/Generic supposed to be
"must-haves" for all LLVM-targets or can/should I ignore some of them?

Ciao, Fabian

On Thu, Aug 16, 2012 at 5:18 AM, Fabian Scheler
<fabian.scheler at gmail.com> wrote:
> Hi everybody,
>
> 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.
> 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.
> When looking for some kind of guide, I am not looking for step-by-step
> instructions to implement these issues, but a well documented back-end
> would be really helpful, here. While being the most complete target,
> the X86 target IMO is much too complex for that purpose.
>
> BTW: are the testcases in test/CodeGen/Generic supposed to be
> "must-haves" for all LLVM-targets or can/should I ignore some of
them?
How important they are probably depends on your target... it's really
a grab-bag of unrelated tests which hasn't been updated in a long
time.  If any of them crash, though, it's probably worth looking into.

-Eli

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