This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: porting GCC


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]