This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How do I stop gcc from loading data into registers when that's not needed?
On Tue, May 22, 2018 at 2:19 AM Paul Koning <paulkoning@comcast.net> wrote:
> > On May 18, 2018, at 2:07 PM, Richard Biener <richard.guenther@gmail.com>
wrote:
> >
> > On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning <
paulkoning@comcast.net> wrote:
> >> Gents,
> >>
> >> In some targets, like pdp11 and vax, most instructions can reference
> >> data in memory directly.
> >>
> >> So when I have "if (x < y) ..." I would expect something like this:
> >>
> >> cmpw x, y
> >> bgeq 1f
> >> ...
> >>
> >> What I actually see, with -O2 and/or -Os, is:
> >>
> >> movw x, r0
> >> movw y, r1
> >> cmpw r0, r1
> >> bgeq 1f
> >> ...
> >>
> >> which is both longer and slower. I can't tell why this happens, or how
> >> to stop it. The machine description has "general_operand" so it
> >> doesn't seem to be the place that forces things into registers.
> >
> > I would expect combine to merge the load and arithmetic and thus it is
eventually the target costing that makes that not succeed.
> >
> > Richard.
> Thanks Richard. I am not having a whole lot of luck figuring out where
precisely I need to adjust or how to make the adjustment. I'm doing the
adjusting on the pdp11 port right now. That has a TARGET_RTX_COSTS hook
which looks fairly plausible. It doesn't currently have a
TARGET_MEMORY_MOVE_COST, or TARGET_ADDRESS_COST, or TARGET_INSN_COST. It
is likely that I need some or all of those to get this working better? If
yes, any hints you can offer where to start?
Sorry, I'm not very familiar with this area of GCC either. Did you confirm
that combine at least tries to merge the memory ops into the instruction?
Maybe it is only RA / reload that will try. You can look at how it works
for x86, for example whether there's already memory ops in the stmts
during RTL expansion which can happen I think when the load has a single
use (and if that works for pdp11).
Richard.
> paul