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: RFC -- update_equiv_regs and friends



  In message <20010301184039.A28544@redhat.com>you write:
  > On Thu, Mar 01, 2001 at 09:27:50PM -0500, John Wehle wrote:
  > >   3) Change update_equiv_regs so it performs the optimization in the
  > >      case of (REG_EQUAL && ! rtx_varies_p) in addition to REG_EQUIV.
  > 
  > Does anyone actually use REG_EQUAL this late?  I thought the main
  > consumer of REG_EQUAL was cse.  If not, then (2) is pointless,
  > since we might as well have not created the thing in the first
  > place.
Yes.  They're used up until local register allocation.  Once we've run
update_equiv_regs I don't believe we make much (if any) use of 
REG_EQUAL notes.

Not surprisingly I've been thinking more about this code in the last couple
days, and I can't convince myself the code to deal with dying registers
in notes for local-alloc is correct either.

While I believe it handles the case where the death note is on the equiv
insn, I don't believe it handles the case where the death note is on a
later insn.  ie consider something like this

insn A where we have an equivalence referencing register X
...
insn B where register X dies
...
insn C where we use the result of insn A.

If we substitute the equivalence from A into C, then we lose because we've
changed the lifetime of register X.

At least I couldn't find anything in the code to handle this case.  Maybe
I missed it; I would appreciate it if folks could chime in with thoughts
on this issue.

Anyway, if I'm right, then I think it is really in our best interest to
avoid making equivalences where the equivalence references a pseudo or a
hard register other than the frame pointer or stack pointer.

jeff


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