[LLVMdev] Passing return values on the stack & storing arbitrary sized integers

[Eli Friedman]

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