Re: Initialize INSN_COND

2011-06-07 Thread Bernd Schmidt
On 06/07/2011 07:39 PM, Alexander Monakov wrote: > > > On Fri, 3 Jun 2011, Bernd Schmidt wrote: > Ok. Although I wonder how sel-sched can end up reusing an entry in h_d_i_d? > > Unlike Haifa scheduler, we recompute INSN_LUIDs for each region. However, we > call sched_deps_{init,finis

Re: Initialize INSN_COND

2011-06-07 Thread Alexander Monakov
On Tue, Jun 7, 2011 at 10:09 PM, Gary Funck wrote: > On 06/07/11 21:39:57, Alexander Monakov wrote: >> 2011-06-07  Alexander Monakov   >> >>       * sel-sched.c (move_op): Use correct type for 'res'.  Verify that >>       code_motion_path_driver returned 0 or 1. >>       (sel_region_finish): Clear

Re: Initialize INSN_COND

2011-06-07 Thread Gary Funck
On 06/07/11 21:39:57, Alexander Monakov wrote: > 2011-06-07 Alexander Monakov > > * sel-sched.c (move_op): Use correct type for 'res'. Verify that > code_motion_path_driver returned 0 or 1. > (sel_region_finish): Clear h_d_i_d. Alexander, will this patch fix the recently rep

Re: Initialize INSN_COND

2011-06-07 Thread Alexander Monakov
On Fri, 3 Jun 2011, Bernd Schmidt wrote: > >> Ok. Although I wonder how sel-sched can end up reusing an entry in > >> h_d_i_d? Unlike Haifa scheduler, we recompute INSN_LUIDs for each region. However, we call sched_deps_{init,finish} once per function (like Haifa) and that makes us reuse entri

Re: Initialize INSN_COND (was: C6X port 5/11: Track predication conditions more accurately)

2011-06-03 Thread Steve Ellcey
> Note that I am using r174594 sources with your patch *AND* with the patch > Bernd proposed for PR 48673 > (http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02470.html). > So this regression may be due to the other change. I will look into it some > more to see if I can figure out which change is

Re: Initialize INSN_COND

2011-06-03 Thread Bernd Schmidt
On 06/03/2011 07:44 PM, Alexander Monakov wrote: > > > On Thu, 2 Jun 2011, Bernd Schmidt wrote: > >> Ok. Although I wonder how sel-sched can end up reusing an entry in >> h_d_i_d? How does it use this machinery? If it's not doing a normal >> forward scan as in sched_analyze, the INSN_COND mechan

Re: Initialize INSN_COND

2011-06-03 Thread Alexander Monakov
On Thu, 2 Jun 2011, Bernd Schmidt wrote: > Ok. Although I wonder how sel-sched can end up reusing an entry in > h_d_i_d? How does it use this machinery? If it's not doing a normal > forward scan as in sched_analyze, the INSN_COND mechanism may break in > other ways. Indeed, that patch did not c

Re: Initialize INSN_COND (was: C6X port 5/11: Track predication conditions more accurately)

2011-06-03 Thread Steve Ellcey
s from other > > previously analyzed instructions. Presuming that sd_init_insn is the > > proper place for that, I'll test the following patch. > > > > > > 2011-06-02 Alexander Monakov > > > > * sched-deps.c (sd_init_insn): Initialize INSN_COND.

Re: Initialize INSN_COND (was: C6X port 5/11: Track predication conditions more accurately)

2011-06-02 Thread Steve Ellcey
is the > proper place for that, I'll test the following patch. > > > 2011-06-02 Alexander Monakov > > * sched-deps.c (sd_init_insn): Initialize INSN_COND. > * sel-sched.c (move_op): Use correct type for 'res'. Verify that > code_motion_p

Re: Initialize INSN_COND

2011-06-02 Thread Bernd Schmidt
; proper place for that, I'll test the following patch. > > > 2011-06-02 Alexander Monakov > > * sched-deps.c (sd_init_insn): Initialize INSN_COND. > * sel-sched.c (move_op): Use correct type for 'res'. Verify that > code_motion_path_driver

Initialize INSN_COND (was: C6X port 5/11: Track predication conditions more accurately)

2011-06-02 Thread Alexander Monakov
ander Monakov * sched-deps.c (sd_init_insn): Initialize INSN_COND. * sel-sched.c (move_op): Use correct type for 'res'. Verify that code_motion_path_driver returned 0 or 1. diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c index 343d03c..e50f7ab 100644 --- a/g