Re: abort dominance:calc_dfs_tree trunck configured for arm-elf target

[amacleod at cygnus dot com]

>> > 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.

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 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