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:
  > My reasoning was that the underlying code generation bug was not an
  > unreasonable assumption.  The assumption is that, if the value of a
  > register is available with the value we need, we're going to use it.
  > So, the bug only showed up because there were two registers with the
  > value we needed, and that was only because the second use didn't
  > inherit the register from the first.
I don't consider that a valid assumption -- there may be a variety of reasons
why we don't want to use that value.

In general, we should never depend on an optimization (like reload inheritance)
to fix a code generation problem.

  > >> (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)).
  > [snip]
  > > However, that equivalence only holds during certain parts of the function
  > > because the value in (reg:SI 130) varies.
  > I think it's ok, (reg:SI 130) doesn't change during the life of the
  > pseudo.
The scope of a REG_EQUIV note is the entire function.  If you read the code
in the register allocators/reload you'll see that if we find a REG_EQUIV note
and the destination is a register, then we mark the register as always
equivalent to the note.  ie, the scope of the note is the entire function.

If the equivalence doesn't hold throughout the function, then we should not
have a REG_EQUIV note -- regardless of the live range of the target pseudo.


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