On 06/13/14 10:59, Kai Tietz wrote:
2014-06-13 17:58 GMT+02:00 Jeff Law <l...@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
