On Wed, May 23, 2018 at 2:50 AM Paul Koning <paulkon...@comcast.net> wrote:
> > On May 22, 2018, at 3:26 PM, Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> >
> >
> > -fdump-rtl-combine-all (or just -da or -dap), and then look at the dump
> > file. Does combine try this combination? If so, it will tell you what
> > the resulting costs are. If not, why does it not try it?
> >
> >> 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?
> >
> > It should, it's a simple reg dependency. In many cases it will even do
> > it if it is not single-use (via a 3->2 combination).
> I examined what gcc does with two simple functions:
> void c2(void)
> {
> if (x < y)
> z = 1;
> else if (x != y)
> z = 42;
> else
> z = 9;
> }
> void c3(void)
> {
> if (x < y)
> z = 1;
> else
> z = 9;
> }
> Two things popped out.
> 1. The original RTL (from the expand phase) has a memory->register move
for x and y in c2, but it doesn't for c3 (it simply generates a
memory/memory compare there). What triggers the different choice in that
phase?
> 2. The reported costs for the various insns are
> r22:HI=['x'] 6
> cmp(r22:HI,r23:HI) 4
> cmp(['x'],['y']) 16
> so the added cost for the memory argument in the cmp is 6 -- the same
as the whole cost for the mov. That certainly explains the behavior. It
isn't what I want it to be. Which target hook(s) are involved in these
numbers? I don't see them in my rtx_costs hook.
The rtx_cost hook. I think the costs above make sense. There's also a
new insn_cost hook but you have to dig whether combine uses that.
Otherwise address_cost might be involved.
Richard.
> paul
