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

Fabian,
> 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.
Side note: you can autogenerate register names :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

Hi Fabian, Anton,

On 22/08/2012 08:25, Fabian Scheler wrote:
>>> 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).
That's *a lot* of work as your processor does not support any operation 
other than mul/div in 64 bit.

Did you try to create a pseudo div/mul instruction and expand it after 
the isel pass ?
Or you may even go further in the pipeline and expand it just before the 
RA with a custom pass.
Not sure if that hook is called again at the RA pass or later on.

Ivan
>
> - 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev