This is the mail archive of the 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: Reload inheritance and auto inc/dec

  In message <>you write:
  > --=-=-=
  > I've been investigating a reload problem that showed up while
  > compiling some code for SH.  Basically, the problem is that reload
  > didn't take advantage of inheritance for a pseudo used in an post_inc
  > memory reference, and, in a subsequence insn, ended up inheriting the
  > value of an out-dated register.
Let me make sure I understand what's happening.

First, right now we're generating incorrect code, right?  Any chance
you'll be able to make a c-torture testcase out of the testcase you've
got right now?

Second, we have a missed optimization (didn't take advantage of inheritance
for a pseudo ...)?

Third, fixing #2 has the side effect of "fixing" #1?

I would claim that while we want to fix the optimization, we also want to
fix the underlying code generation bug.

  > (insn 199 939 200 (set (reg:QI 120)
  >         (mem/s:QI (post_inc:SI (reg:SI 130)) 0)) 89 {movqi_i} (insn_list 93
  > 9 (nil))
  >     (expr_list:REG_INC (reg:SI 130)
  >         (nil)))
  > [snip]
  > (insn 220 218 221 (set (reg:QI 131)
  >         (mem/s:QI (reg:SI 130) 0)) 89 {movqi_i} (insn_list 218 (nil))
  >     (expr_list:REG_EQUIV (mem/s:QI (reg:SI 130) 0)
  >         (nil)))
This seems rather odd to me -- we've got a REG_EQUIV note which makes an
equivalence between (reg:QI 131) and (mem:QI (reg:SI 130)).

Note the documentation for REG_EQUIV:

  For @code{REG_EQUIV}, the register is equivalent to @var{op} throughout
  the entire function, and could validly be replaced in all its
  occurrences by @var{op}.  (``Validly'' here refers to the data flow of
  the program; simple replacement may make some insns invalid.)  For
  example, when a constant is loaded into a register that is never
  assigned any other value, this kind of note is used.

However, that equivalence only holds during certain parts of the function
because the value in (reg:SI 130) varies.

I think the REG_EQUIV note is bogus.

  > 	* reload1.c (choose_reload_regs): Search for equivalences if `in'
  > 	and `out' are the same rtx.
Let's table this until we fix the real code gen bug, then come back to it
as an optimization.


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