This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: porting GCC
- To: "Krzysztof Matula" <km at taboo dot eu dot org>
- Subject: Re: porting GCC
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Thu, 01 Feb 2001 11:09:22 +0000
- cc: gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> Hi!
>
> I am extending one of GCC ports an I have the following problem:
>
> I need to detect all references to to objects in data segment (SYMBOL_REF/v)
> and modify rtx in such way, that the segment base address is added to the
> offset (represented by the symbol itself). Generating such rtx is not a
> problem, but I don't know where to connect this. In the code I am extending
> such replacement is made in two "define_expand"-s. One of them looks like
> this:
>
> set(reg)(plus:SI((general_operand)(general_operand)))
>
> As a result new rtx is generated that takes the segment base address and
> adds a symbol offset:
>
> set(reg)(plus:SI((reg)(SYMBOL_REF)))
>
> ...such rtl matches one of the "define_insn"-s.
>
> The problm is that sometimes during optimizations GCC creates exactly the
> same rtl, and it matches the same "define_insn" without going through
> "define_expand". The rtl modification for proper data segment access is not
> performed...
>
> I think I have to flag the rtx generated in define_expand in some way and
> setup the predicate used in define_insn to reject unflagged symbol refs...
>
> Is that the right way??? If so, how can I flag the rtx??? Or, maybe I should
> do this in a different way???
>
> KM
>
>
This is similar to the problem faced by many ports when generating PIC
code. The normal approach is to wrap symbol refs in an UNSPEC and then
restrict the recognizer rules to only allow such wrapped symbols. Take a
look at how other machines handle this case for PIC.
R.