Scheduler cleanups, 1/N

[H.J. Lu]

On Mon, Apr 4, 2011 at 8:07 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/02/2011 02:55 AM, H.J. Lu wrote:
>> On Thu, Mar 24, 2011 at 6:07 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>> I have a number of patches that will be necessary for a new target. Some
>>> of these can be applied now as cleanups, so I'm submit them now.
>>>
>>> This changes the schedule_block main loop not to move instructions while
>>> computing the schedule. Instead, we collect them in a VEC and modify the
>>> RTL afterwards. The real motivation for this is to add support for
>>> backtracking later.
>>>
>>> Bootstrapped and tested on i686-linux. No changes in generated code on
>>> any of my testcases.
>>>
>>
>> This caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403
>
> I eventually managed to reproduce it, and even figured out what I'd
> stupidly been doing wrong with my bootstraps which caused me not to see
> this.
>
> There were a few places where last_scheduled_insn wasn't just examined
> on its own, but code wanted to walk backwards and forwards from it. This
> patch adapts them. I've also included Steven's patch from the bugzilla.
>
> Bootstrapped on i686-linux. Also tested, but I need to rerun those since
> there were other changes in the tree which were causing some failures.
> I've also built a powerpc-linux cross compiler, and compiled my set of
> examples with "-fsched-stalled-insns-dep=4 -msched-costly-dep=all
> -fsched-stalled-insns", with both patches included and with both patches
> removed, and found no code generation differences. I also did a run
> using "-fdbg-cnt=sched_insn:20", which exposed a preexisting bug in
> schedule_block (avoiding a requeue for the first insn, but not placing
> it back in the ready list).
>
> Ok after retest?
>

Could you please mention PR 48403 in your ChangeLog?

Thanks.


-- 
H.J.