[llvm-dev] Getting up to speed with llvm backends. Machine Instruction operands.
Walter Zambotti via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 12 21:35:40 PDT 2020
Thanks for the MSP430 pointer I will look into that.
In relation to my concerns regarding the TriCore ABI. It is good to know
this was specific to the calling convention.
The 6309 does not have a lot of registers to pass arguments. It is all be
I believe the current C compiler will use the only 16 bit accumulator to
return a value regardless of type. So unless I extend the ABI that
shouldn't be a problem.
I will continue my self-education by study the MSP430 backend.
From: David Greene [mailto:greened at obbligato.org]
Sent: Friday, 13 March 2020 3:56 AM
To: Walter Zambotti <zambotti at iinet.net.au>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Getting up to speed with llvm backends. Machine
David Greene via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> I ask because the backend I would like to target the Hitachi/Motorola
>> 6309/6809 which too provides dedicated indexing (addressing)
>> registers. In fact in all binary operations the second operand is
>> either immediate or some kind of a memory reference via a
>> index/address register.
> I'm not familiar with this architecture, but I will try to answer
> question as best I can.
I missed this the first time around so I'll add it now.
Special index/address registers are really no problem. They're just a
different register class. There are target hooks you would redefine to
implement copying between registers of different classes when the code
generator realizes the value it needs is in the "wrong" register class.
It *should* mostly just fall out given correct register class definitions
and typing the TableGen pattern inputs correctly.
I think the concern raised by the thesis paper is very specific to calling
convention. The TriCore ABI apparently requires that arguments/return
values of pointer and integer type be passed in different register classes.
Does your target have a similar requirement? If not, then I don't think you
have anything to worry about.
More information about the llvm-dev