abort dominance:calc_dfs_tree trunck configured for arm-elf target

Graham Stott grahams@redhat.com
Sat Jul 28 07:56:00 GMT 2001


amacleod@cygnus.com wrote:
> 
> >> > The following almost trival peice of code triggers an abort
> >> > in calc_dfs_tree because di->nodes == 7 and n_basic_blocks == 8
> >> >
> >> > ---------------------------sf_erf.c---------------------------------
> >> > extern float erfcf (float);
> >> >
> >> > extern const float one,two;
> >> >
> >> > float
> >> > erfcf(float x)
> >> > {
> >> >         int hx,ix;
> >> >
> >> >         hx = one;
> >> >         ix = hx & 0x7fffffff;
> >> >         if(ix >= 0x7f800000)
> >> >             return (float)(((unsigned)hx>>31)<<1)+one/x;
> >> >         else
> >> >           return two;
> >> > }
> >> > ---------------------------------------------------------------------
> >>
> >> I think I've identified the problem.
> >>
> >> The CFG had an unreachable block which appears to trigger the abort
> >> because the unreachable block is never processed during the DFS.
> >>
> 
> Ive got the same problem in reload1.c on IA64 (-O2) when attempting to
> bootstrap with another patch...
> 
> The graph looks like:
> 
>      bb0
>       |
>      bb1
>       |  \
> bb3  bb2  bb4
>    \_ |    |
>      bb5 _/
>       | /
>      bb6
> 
> bb3 is never assigned a dfs number, so it aborts.
> 
Yep that's basically what my CFG looked like.

> If you are doing it in reverse, it makes allowances, but not forward:
> 
>       /* In the post-dom case we may have nodes without a path to EXIT_BLOCK.
>          They are reverse-unreachable.  In the dom-case we disallow such
>          nodes, but in post-dom we have to deal with them, so we simply
>          include them in the DFS tree which actually becomes a forest.  */
> 
> >> I added a call to cleanup_cfg (CLEANUP_EXEPENSIVE) before the call to
> >> schedule_insns() toplev.c which removed the unreachable block from the
> CFG.
> 
> So the question is do we need to run cleanup_cfg () as you have done, or
> can we do the same thing as the post-dom case and keep on trucking, or
> simply not abort even though bb3 has no value?
> 
I can see at least one advantage of running cleanup_cfg before calculating
the dominator info it may reduce the number of basic blocks and on large
routines this will help our memory usage at the expense slightly longer
compile times.

> I didnt try it with the call to cleanup_cfg (), but it does bootstrap
> with simply not aborting and also assigning values like the post-dom case.
> I'd be suprised if it didn't bootstrap with the cleanup_cfg call too...
> 
> The test that aborts doesnt really check that there is no
> path, from entry to exit, only that every basic block
> was included. We could also change this check to see if
> there was a value assigned to the exit block if thats what
> the check is really suppose to do.
> 
> >>  /* This aborts e.g. when there is _no_ path from ENTRY to EXIT at all.  */
> >>   if (di->nodes != (unsigned int) n_basic_blocks + 1)
> >>     abort ();
> 
> Lots of choices, whats the right thing to do?
> 
> Andrew

Not sure but I would be inclined to disable the abort if it triggers on a valid
CFG.

Graham



More information about the Gcc-bugs mailing list