Joern RENNECKE <joern.rennecke@xxxxxx> wrote on 07.11.2005 20:44:30:
> Exactly what piece of code are you considering to remove? If you
> the removal of PLUS function invariants, I'll expect that to lead to
> performance regressions.
> IIRC the memory address RHS case was actually the main problem that
> the code addreses - cse and/or loop hoist out tons of frame+offset sums,
> which can't all be allocated to hard registers and thus get spilled to
> the stack.
> So instead of calculating a simple frame+offset sum, we calculated a more
> complicated (larger offset) frame+offset sum to fetch a stack slot value
> contains the wanted frame+offset sum.
> Putting these function invariants into reg_equiv_constant allowed us to
> basically re-materialize the sums.
Substituting invariants into *address* contexts (i.e. into the address
within a memory operand, or else into an address operand) is fine.
find_reloads_address is supposed to handle PLUS anyway.
The problem comes when a PLUS invariant is substituted into a *non-address*
context (i.e. where find_reloads_address will not be called) -- right now
any register_operand anywhere can be replaced by a PLUS, and reload needs
to handle all such cases.
Mit freundlichen Gruessen / Best Regards
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@xxxxxxxxxx