This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]