[patch i386]: Combine memory and indirect jump

[Jeff Law]

On 06/23/14 08:32, Richard Biener wrote:
> On Mon, Jun 23, 2014 at 4:13 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 06/20/2014 02:59 PM, Kai Tietz wrote:
>>> So I suggest following change of passes.def:
>>>
>>> Index: passes.def
>>> ===================================================================
>>> --- passes.def  (Revision 211850)
>>> +++ passes.def  (Arbeitskopie)
>>> @@ -384,7 +384,6 @@ along with GCC; see the file COPYING3.  If not see
>>>            NEXT_PASS (pass_rtl_dse2);
>>>            NEXT_PASS (pass_stack_adjustments);
>>>            NEXT_PASS (pass_jump2);
>>> -         NEXT_PASS (pass_peephole2);
>>>            NEXT_PASS (pass_if_after_reload);
>>>            NEXT_PASS (pass_regrename);
>>>            NEXT_PASS (pass_cprop_hardreg);
>>> @@ -391,6 +390,7 @@ along with GCC; see the file COPYING3.  If not see
>>>            NEXT_PASS (pass_fast_rtl_dce);
>>>            NEXT_PASS (pass_duplicate_computed_gotos);
>>>            NEXT_PASS (pass_reorder_blocks);
>>> +         NEXT_PASS (pass_peephole2);
>>>            NEXT_PASS (pass_branch_target_load_optimize2);
>>>            NEXT_PASS (pass_leaf_regs);
>>>            NEXT_PASS (pass_split_before_sched2);
>>
>> Looks good to me.  I guess just keep an eye out for bug reports for other ports.
>
> Maybe put a comment here because it looks like a random placement to me
> which would be obvious to revert.  peepholing before if-after-reload sounds
> good anyway.
Definitely need a comment on the pass placement.

> Btw, there is now no DCE after peephole2?  Is peephole2 expected to
> cleanup after itself?
There were cases where we wanted to change the insns we would output to 
fit into the 4:1:1 issue model of the PPro, but to do so we needed to 
know what registers were live/dead so that we could rewrite the insns 
appropriately.  It didn't fit well into what we could do in the 
splitters and the old peephole ran too late.  Dead code wasn't ever 
really considered.  At least that's my recollection.  RTH might recall more.

I think it'd be worth an experiment here, but I think that can/should 
happen independently of Kai's patch.  Arguably the scheduler should have 
all the necessary dataflow information to quickly identify any dead code.

Jeff