> >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.
Yes. What I mean is that peephole2s are still fragile in ways that
are unique to peephole2; they need to check manually whether registers
are dead, whether registers overlap, whether constraints match. I'd be
surprised if there would not be any fallout from adding a later peephole2
pass. Those of course are target bugs, but it's still fallout. Doing
this on the back of an x86 patch without testing anywhere else is not
very friendly :-P
> >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
That's no reason to run more after the scheduler, quite the opposite.
> -- 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.
The very first example in the define_peephole2 description in the manual,
which is for x86, shows a peephole that only makes sense before scheduling
("This pattern tries to split a load from its use in the hope that we'll
be able to schedule around the memory load latency.")
You could well be right that there is no measurable difference on any
target; but we won't know without measuring.
Segher
