This is the mail archive of the gcc-patches@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: PATCH: PA PIC symbolic memory fix PART 2




  In message <200102262046.PAA08962@hiauly1.hia.nrc.ca>you write:
  > >   > On a related issue, I tried to determine why defining IS_RELOADING_PS
  > EUDO_P
  > >   > is necessary for non pic code.  It seems without it that the followin
  > g
  > >   > substitution occasionally occurs into the catch all move insn at line
  >  2099
  > >   > in pa.md:
  > >   > 
  > >   > (set (reg) (symbol))
  > >   > 
  > >   > Again, the insn at 2099 can't handle this.  I hadn't fully appreciate
  > d
  > >   > that CSE simplifies LO_SUM MEMs to just the constant symbol reference
  > .
  > > That shouldn't be happening.  That's not a valid insn.  I'd suggest you
  > > dig into how/why that happened.
  > 
  > Take a look at the REG_EQUIV notes that are being put on non PIC
  > LO_SUMs.  Here is an random example from the lreg pass:
  > 
  > (insn 124 24 123 (set (reg/f:SI 96)
  >         (high:SI (symbol_ref:SI ("defs")))) 82 {*pa.md:2354} (nil)
  >     (expr_list:REG_EQUIV (high:SI (symbol_ref:SI ("defs")))
  >         (nil)))
  > 
  > (insn 123 124 25 (set (reg/f:SI 95)
  >         (lo_sum:SI (reg/f:SI 96)
  >             (symbol_ref:SI ("defs")))) 88 {*pa.md:2434} (nil)
  >     (expr_list:REG_DEAD (reg/f:SI 96)
  >         (expr_list:REG_EQUIV (symbol_ref:SI ("defs"))
  >             (nil))))
  > 
  > If you think the form of the REG_EQUIV notes are ok, I will try to figure
  > out what is happening in reload.
Ok.  Yes.  That makes sense.

We'll expand this into a new HIGH/LO_SUM sequence in movsi and
secondary_reload_class should ensure that we have %r1 available as a
scratch.
jeff


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