Remy Saissy wrote:
>if I understand well, to make gcc generating rtx according to an
>__attribute__((far("fs"))) on a pointer I only have to add or modify
>rtx in the i386.md file and add an UNSPEC among the constants ?
No, the work you need to on the backend, adding an UNSPEC constant to
"i386.md" and writing code to handle the UNSPEC in "i386.c" is just the
easy part.
> What I understand is that there is two kind of managment for attribute :
Attributes are handled in various different ways depending on what the
attribute does. To handle your case correctly, you'ld have to change how
the tree to RTL conversion generates RTL addresses expressions whenever
a pointer with the "far" attribute is dereferenced. This is probably
going to be a lot work.
> Therefore, I can consider the following relationship:
> (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
> | | | |
> \/ \/ \/ \/
> int * __attribute__((far("fs"))) p;
No, that's not what the RTL expression represents. Declarations aren't
represented in RTL. The example RTL expression I gave is just an
expression, not a full RTL instruction. It's something that could be
used as the memory operand of an instruction. The RTL expression I gave
would correspond to a C expression (not a statement) like this:
*(int * __atribute__((far("fs")))) var
> does (reg:HI fs) care about the type of the parameter fs ?
See the GCC Internals documentation. In my example, since I don't know
what the actual hard register number you assigned to the FS segment
register, I just put "fs" in the place where the actual register number
would appear. Similarily, the "var" in "(reg:SI var)" represents
the number of the pseudo-register GCC would allocate for an automatic
variable named "var".
> how does gcc recognize such an expression ?
Since this expression is a memory operand, it's recognized by the
GO_IF_LEGITIMATE_ADDRESS() macro. In the i386 port, that's implemented
by legitimate_address_p() in "i386.c".
Ross Ridge
