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

[Fabian Scheler]

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