Re: [patch i386]: Combine memory and indirect jump

[Jeff Law <law at redhat dot com>]

On 06/13/14 10:59, Kai Tietz wrote:
> 2014-06-13 17:58 GMT+02:00 Jeff Law <law@redhat.com>:
> > On 06/13/14 09:56, Richard Henderson wrote:
> > > On 06/13/2014 08:36 AM, Jeff Law wrote:
> > > > So you may have answered this already, but why can't this be a combiner
> > > > pattern?
> > >
> > >
> > > Until pass_duplicate_computed_gotos, we (intentionally) have a single
> > > indirect
> > > branch in the entire function.  This vastly reduces the size of the CFG.
> >
> > Ah, the factoring bits.  Should have known.
> >
> >
> > > Peep2 is currently running before d_c_g, so currently Kai can't solve this
> > > problem in peep2.
> > >
> > > I don't think peep2 should run after sched2, but I'll bet we can reorder
> > > things
> > > a bit so that d_c_g runs before peep2.
> >
> > Yea, seems worth a try.
> >
> > jeff
>
> Well, I tested to put the second sched2 pass before the sched2 pass.
> That works in general.  There are just some opportunties which weren't
> caught then.  I attached a sample, which demonstrates that pretty
> well.  I noticed that I had to put that pass behind reload blocks was
> necessary for better hit-rate of the peephole optimization.
So can you tell us why this sample code misses opportunities?  Otherwise 
we have to dig into it ourselves to tease out that information.

I think we're zeroing in on a path to move d_c_g before peep2, but I'd 
like to have a clearer understanding of why we'd still be missing 
opportunities.  If we can avoid running peep2 twice, that'd be good.

jeff