Comments

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?
Bernd
* haifa-sched.c (nonscheduled_insns_begin): New static variable.
(rank_for_schedule): Use scheduled_insns vector instead of
last_scheduled_insn.
(ok_for_early_queue_removal): Likewise.
(queue_to_ready): Search forward in nonscheduled_insns_begin if
we have a dbg_cnt.
(choose_ready): Likewise.
(commit_schedule): Use VEC_iterate.
(schedule_block): Initialize nonscheduled_insns_begin. If we have
a dbg_cnt, use it and ensure the first insn is in the ready list.
(haifa_sched_init): Allocate scheduled_insns.
(sched_extend_ready_list): Don't allocate it; reserve space.
(haifa_sched_finish): Free it.

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.

On 04/04/2011 11:07 AM, Bernd Schmidt wrote:
>> 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?>
Ok, thanks.

On Mon, Apr 4, 2011 at 9:34 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> On 04/04/2011 11:07 AM, Bernd Schmidt wrote:>>>> 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?>>> Ok, thanks.>>
I bootstrapped it on Linux/x86-64 and checked it in.
Thanks.