On Fri, Apr 5, 2013 at 10:22 AM, Eric Botcazou wrote:
>> Thinking about this some more: This could be fixed by inserting a
>> machine-specific pass just after delayed-branch scheduling, like in
>> the attached patch. I think the same is possible with the dbr_schedule
>> call in the MIPS backend.
>>
>> Eric, what do you think of this approach?
>
> No objections on principle from a SPARC viewpoint. But can we really control
> when the pass is run with register_pass? Because it needs to be run _before_
> branch shortening.
Yes, we can control that. In this particular case, register_pass() is
told to insert the pass immediately after the first (and only)
instance of the pass named "dbr" i.e. pass_delay_slots.
position_pass() will look through the pass list and performs the
insertion in the right place. The new pass is inserted between
pass_delay_slots and pass_split_for_shorten_branches.
Without the inserted pass, before the patch, the pass chain looks like this:
NEXT_PASS (pass_machine_reorg);
// sparc_reorg calls cleanup_barriers and dbr_schedule
NEXT_PASS (pass_cleanup_barriers);
NEXT_PASS (pass_delay_slots);
NEXT_PASS (pass_split_for_shorten_branches);
NEXT_PASS (pass_convert_to_eh_region_ranges);
NEXT_PASS (pass_shorten_branches);
After the patch, it looks like this:
NEXT_PASS (pass_machine_reorg); // now a NOP for sparc
NEXT_PASS (pass_cleanup_barriers);
NEXT_PASS (pass_delay_slots);
NEXT_PASS (pass_work_around_errata);
NEXT_PASS (pass_split_for_shorten_branches);
NEXT_PASS (pass_convert_to_eh_region_ranges);
NEXT_PASS (pass_shorten_branches);
I've confirmed this also by printing the name for each pass in the chain.
Ciao!
Steven
