This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [cft] fix 24160
- From: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- To: Joern RENNECKE <joern dot rennecke at st dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Mon, 7 Nov 2005 20:58:31 +0100
- Subject: Re: [cft] fix 24160
Joern RENNECKE <joern.rennecke@st.com> wrote on 07.11.2005 20:44:30:
> Exactly what piece of code are you considering to remove? If you
consider
> the removal of PLUS function invariants, I'll expect that to lead to
major
> 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
> that
> 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
Ulrich Weigand
--
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@de.ibm.com