Patch to improve register elimination

John Wehle john@feith.com
Fri Feb 12 15:31:00 GMT 1999


> Consider if the last block does not initially have a reference to the frame
> pointer.  So we initially don't care about the differing offsets involing
> the frame pointer.
> 
> But later we end up eliminating some other eliminable register (arg pointer
> for example) to be a frame pointer reference. 
> 
> Will your code handle that correctly?

I believe so.  My impression is that a chain of eliminations will be
processed by eliminate_regs and eliminate_rgs_in_insn one link at a
time with reload calling set_inital_label_offset (which calls
set_label_offsets) and calculate_needs_all_insns calling
set_label_offsets between each link so if the chain is:

  ARG -> FRAME
  FRAME -> STACK

and the ARG pointer is used in the last block and the offset between
the FRAME and STACK isn't known then the first pass of reload will
replace ARG with FRAME and (due to my change) not disable the FRAME
to STACK elimination.  The second pass of reload will disable the
FRAME to STACK elimination since the offset isn't known and the
FRAME is being used.

> This could be made more effective using dataflow analysis to propagate this
> info around the cfg.
> ...
> Interested in trying to do a more global version of this algorithm?

Not at the moment.  My main problem was the EXIT_IGNORE_STACK optimization
causing the compiler to believe that the frame pointer couldn't be eliminated
by the stack pointer due to the final stack adjustment being deleted.  This
problem appears to be solved by my patch.

Granted I haven't given this a lot of thought, however is it actually all
that common for an elimination to be disabled due to the offset being
unknown at a label (other than due to the EXIT_IGNORE_STACK optimization)?

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------



More information about the Gcc-patches mailing list