This is the mail archive of the
mailing list for the GCC project.
Re: [patch i386]: Combine memory and indirect jump
- From: Jeff Law <law at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Fri, 13 Jun 2014 09:29:56 -0600
- Subject: Re: [patch i386]: Combine memory and indirect jump
- Authentication-results: sourceware.org; auth=none
- References: <CAEwic4brJeBvoe+J5ss=Qo+=qoo-=2nV0FnjdUxBhm-fV4aqeQ at mail dot gmail dot com> <CABu31nNwUoLaAo0QcD-3O1QYhBWpLsYuH0cMS-XOgz2W+8KMAA at mail dot gmail dot com> <CAEwic4Zwd4HECD+kxtkouyA3Urbyzh2NFar7kZ5XLdNnUK9w6A at mail dot gmail dot com> <CAEwic4anzQysfHqfQGgKF_Hu-c_hLY+mkWr2CzERVe=gQ5AWRw at mail dot gmail dot com> <20140612185258 dot GA9914 at gate dot crashing dot org> <CAEwic4aF2etKf1PXm4Bo-7O-Y7Eb3NN_2jG0-zTLcW46yDd_-w at mail dot gmail dot com> <20140612210616 dot GA13489 at gate dot crashing dot org>
On 06/12/14 15:06, Segher Boessenkool wrote:
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
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.
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.
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.
My other concern is that running peepholes again after scheduling
could easily generate worse code.
I'd be surprised if enough things fall out of peep2 changes to be