On 06/12/14 15:06, Segher Boessenkool wrote:
Will that work on other targets?
Well, this is the only point I am a bit concerned too. In general I
wouldn't expect here any issues to run peephole after scheduling, as
peephole doesn't do anything a new run of ira/lra would require.
My concern is that peepholes are rather fragile, so imho it is not
inconceivable that some target will generate wrong code when you add
an extra (later) peephole pass. Of course, we are in stage1.
peephole2 is significantly robust than the original peephole pass;
largely because peep2 is required to generate real insns that can be
processed by the scheduler and other passes. Another pass or moving the
pass to a different location in the pipeline shouldn't be inherently
problematical.
The original peephole pass ran so late that ports could play it pretty
fast and loose and changing its location in the pipeline or adding
another pass would be ill-advised.
My other concern is that running peepholes again after scheduling
could easily generate worse code.
That's always been the the case for anything which runs after the
scheduler -- such passes perturb the work of the scheduler. We've
effectively ignored the effects of reg-stack, delay slot filling and the
old peephole pass in terms of their effect on the schedule.
I'd be surprised if enough things fall out of peep2 changes to be
measurable.
Jeff
