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: Your recent reload changes


  In message <20000822140310.A25650@cygnus.com>you write:
  > On Tue, Aug 22, 2000 at 11:01:07AM -0700, Richard Henderson wrote:
  > > On Tue, Aug 22, 2000 at 09:45:01AM -0600, Jeffrey A Law wrote:
  > > > However, after your patch we get the following reloads:
  > > > 
  > > > Reload 0: R1_REGS, RELOAD_FOR_INPUT (opnum = 0), can't combine, 
  > > > secondary_reload_p
  > > > Reload 1: reload_in (SI) = (high:SI (symbol_ref:SI ("warn_std_ptr")))
  > > >         GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't comb
  > ine
  > > 
  > > This is the problem.  The secondary reload should have the same
  > > lifetime as its primary, but doesn't.  I'll see about fixing this.
  > 
  > Bother.  Even after fixing this it still doesn't work.  We've got
  > 
  > Reload 0: R1_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0),
  > 	can't combine, secondary_reload_p
  > Reload 1: reload_in (SI) = (high:SI (symbol_ref:SI ("warn_std_ptr")))
  >         GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
  >         reload_in_reg: (reg:SI 466)
  >         secondary_in_reload = 0
  >         secondary_in_icode = reload_insi
  > Reload 2: reload_out (SI) = (mem/f:SI (lo_sum:SI (reg:SI 466)
  >                                 (symbol_ref:SI ("warn_std_ptr"))) 110)
  >         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
  >         reload_out_reg: (mem/f:SI (lo_sum:SI (reg:SI 466)
  >                             (symbol_ref:SI ("warn_std_ptr"))) 110)
  > Reload 3: R1_REGS, RELOAD_FOR_INPUT (opnum = 1),
  > 	can't combine, secondary_reload_p
  > Reload 4: reload_in (SI) = (symbol_ref:SI ("warn_std"))
  >         GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
  >         reload_in_reg: (reg:SI 467)
  >         secondary_in_reload = 3
  >         secondary_in_icode = reload_insi
  > 
  > I'm not quite sure the distinction between OPERAND_ADDRESS and INPUT,
  > as they're both inputs, of a sort.  But what it means is that we've
  > still got overlapping lifetimes for the R1 secondary reloads.
Hmmm, based on my quick reading of reload1.c, I would think that would
work.  Reloads #3 & #4 would occur, then #1, #2.  Is it the case that
we don't realize the RELOAD_FOR_INPUT reload in #3 dies before the
reload for #1?


  > The Problem here is that we've gone from one extreme to another.  From
  > no overlapping lifetimes between the secondary and primary to completely
  > overlapping lifetimes.  But that's just as inaccurate.  What we need is
  > for secondary reloads (with reload_in/out) to be live until the end of
  > the reload insn.  When using something like INPUT_ADDRESS they're
  > considered live until the beginning of the reload insn.
OK. I get it.

I wonder why #0 & #1 aren't RELOAD_FOR_OUTPUT_ADDRESS or something like
that since they're for the output value.


  > So, whaddaya wanna do?  Revert the whole thing and find some other
  > workaround for ia64 (OImode reloads?  Eek.), add yet another lifetime,
  > or see how much work finishing Bernd's reload dependancy bit would take?
I'm not sure.  The reload dependency stuff is really the right way to go
to describe all this stuff.  But I'm not sure if we've got the time right
now to tackle that kind of redesign.  I haven't looked at it in the last
month or so, but my understanding was most of the basic bits where ready,
but that we were going to need a fair amount of test & benchmark time
(the former simply because it significantly revamps how we allocate
reload regs, the latter because it zapps all the code which tried to
optimize reloads).

jeff


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