| Message ID | 4F859244.9060600@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Apr 11, 2012 at 4:16 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > The order of calls to sched_rgn_init and sched_init differs between > sched-rgn and sel-sched. This caused a scheduler patch I was working on > to segfault once sel-sched was enabled. The following patch swaps the > two function calls. > > Bootstrapped & tested on i686-linux. Ok? Ok. Thanks, Richard. > > Bernd
On Wed, 11 Apr 2012, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 4:16 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > > The order of calls to sched_rgn_init and sched_init differs between > > sched-rgn and sel-sched. This caused a scheduler patch I was working on > > to segfault once sel-sched was enabled. The following patch swaps the > > two function calls. > > > > Bootstrapped & tested on i686-linux. Ok? > > Ok. > > Thanks, > Richard. Actually, this causes miscompilations with selective scheduler when -fsel-sched-pipelining is enabled (as it is with -O3 on ia64). The reason is, with that flag we build custom regions that consist of a loop body and its preheader in sel_find_rgns, which is called from sched_rgn_init. We require that sched_init is called afterwards, so that DF data is computed for any new blocks that might have been created (i.e. preheaders); it's possible that DF is not the only thing that forces this order. Bernd, could you elaborate on the segfault you had seen? Perhaps we could offer some advice on fixing it then. In the meanwhile, could you revert your patch? I'm sorry to point out this problem after the patch had been committed, but it's not immediately obvious :) Andrey or I will add an explanatory comment in sel-sched afterwards. Alexander
On 04/17/2012 03:33 PM, Alexander Monakov wrote: > Bernd, could you elaborate on the segfault you had seen? Perhaps we could > offer some advice on fixing it then. It was only seen with another patch which modified the sched-rgn initialization code. > In the meanwhile, could you revert your patch? I'm sorry to point out this > problem after the patch had been committed, but it's not immediately obvious :) > Andrey or I will add an explanatory comment in sel-sched afterwards. Will revert for now. In general I think it would be better to change sel-sched so that the init functions can always be called in the same order, so as to avoid unnecessary surprises. Bernd
Index: gcc/sel-sched.c =================================================================== --- gcc/sel-sched.c (revision 364953) +++ gcc/sel-sched.c (working copy) @@ -7616,8 +7616,8 @@ sel_global_init (void) sel_setup_sched_infos (); setup_sched_dump (); - sched_rgn_init (false); sched_init (); + sched_rgn_init (false); sched_init_bbs (); /* Reset AFTER_RECOVERY if it has been set by the 1st scheduler pass. */