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

Fabian Scheler fabian.scheler at gmail.com
Tue Aug 21 23:25:36 PDT 2012


>> here are the definitions of these register classes:
>>
>> // Data register class
>> def DR : RegisterClass<"TriCore", [i32], 32,
>>                        (add D0, D1, D2,  D3,  D4,  D5,  D6,  D7,
>>                             D8, D9, D10, D11, D12, D13, D14, D15)>;
>>
>> // Extended-size data register class
>> def ER : RegisterClass<"TriCore", [i64], 32,
>>                        (add E0, E2, E4, E6, E8, E10, E12, E14)> {
>>   let SubRegClasses = [(DR sub_even, sub_odd)];
>> }
>>
>> And the DX and EX registers are defined this way:
> The regclasses look fine... So, you need to figure out why
> getRepRegClassFor() returns NULL in this case.

Well, that's rather easy :-) The register class is not registered in
the constructor of TriCoreTargetLowering. Maybe, some background is
missing here:

- I added the ER register class for MVT::i64 and I had to take care of
quite a lot of stuff as the TriCore does not really support 64-bit
operations (it just offers these register pairs but almost no
operations working on them).

- Eli mentioned that is a quite common mistake to register such
register classes although the processor does not support many
operations on the according value types. It causes much more work in
the specific back-end as type legalization no longer takes care of
such nodes. It definitely would be much easier if I just had to take
care of some special instructions on the TriCore that involve ER
registers (like multiplication/division).

- However, the segfault caused by the NULL-pointer returned by
getRepRegClassFor() is the reason why I added this register class and
used a lot of setOperationActions, setLoadExtAction, ... or lowered
some thins manually.

> Side note: you can autogenerate register names :)

Nice, saves typing. Is there an example I can have a look at. Most
targets I examined seem to do this explicitly.

Ciao, Fabian



More information about the llvm-dev mailing list