On 12 April 2006 06:48, Frank Riese wrote:
> Yes, you're right. When I started writing this backend I didn't have much
> experience with it. I took the smallest backend I could find and tried to
> adjust it to me needs. The number of macros in the internals docs was a bit
> overwhelming at first and GCC kept segfaulting on me - something I'm
> definately not used to from GCC. So, I was happy when I had something
> working to start with. But now I think it would have been cleaner to start
> from scratch.
Or you could track down the segfaults to bugs in the modifications you've
made; these are very often a sign that you've made a false assumption about
what's in an rtx and as a consequence used the wrong kind of accessors (XINT,
XEXP, etc) on it or its operands. Get used to the habit of adding lots of
calls to print_rtl - under the control of a target flag, for preference! It
is still easier to start with an existing backend that's similar to your
target than to build one from complete scratch.
>> #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \
>> if (REG_P (X)) \
>> goto LABEL;
>
> I tried that out today. I wasn't sure about the exact contexts in which this
> macro is used.
[ I'll try and answer this, because I've just been studying this area of the
compiler myself, and the revision will do me good. Please bear in mind that
what I say is not authoritative as it's fairly new to me and so I may have
some errors in the details, but the outline is right. E&OE, caveat lector! ]
It's used when gcc needs to form a (mem X) rtx and wants to know what kind
of rtxen can be used (as the 'X') to represent the cpu's natural addressing
modes as understood by the assembler. Whatever forms of rtx are accepted by
G_I_L_A will be the forms of rtx passed to PRINT_OPERAND_ADDRESS when they
crop up as the operands matched by the constraints in an insn pattern; when
code generation matches some rtl with a bunch of operands against a
define_insn pattern with operand constraints, it starts outputting the output
template from the define insn and calls P_O_A with the relevant operand when
it performs an operand substitution.
So, e.g. if your CPU had register, register+offset, and immediate addressing
modes, G_I_L_A would accept 1) a (reg ...) rtx 2) a (plus (reg ...) (const_int
...)) rtx and 3) a (const_int ...) rtx. Then, in P_O_A, you might use
sprintf (STREAM, "[r%d]", REGNO(X))
if X had code REG, or
sprintf (STREAM, "[0x%x, r%d]", INTVAL(XEXP(X, 1)), REGNO(XEXP(X,
0)));
for the PLUS or just
sprintf (STREAM, "[0x%x]", INTVAL(X))
for the CONST_INT that represents your immediate addressing mode. (Note that
I might have the form of the (plus) rtx slightly wrong there w.r.t. insn
canonicalisation and I'm not sure whether you might not also see any (minus)
rtxen likewise).
cheers,
DaveK
--
Can't think of a witty .sigline today....
