On Tue, May 22, 2018 at 2:19 AM Paul Koning <paulkon...@comcast.net> wrote:
> > On May 18, 2018, at 2:07 PM, Richard Biener <richard.guent...@gmail.com> wrote: > > > > On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning < paulkon...@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
