reorder_block space requirements (was Re: test patch for computed gotos)

Michael Matz matz@suse.de
Fri Mar 7 15:15:00 GMT 2003


Hi,

On Fri, 7 Mar 2003, Brad Lucier wrote:

> Ah, maybe having -freorder-blocks enabled at -O1 would be premature ...
> I tried it on all.i, and cc1 took almost 1GB of virtual memory; since I
> have only 1GB or so of RAM in my machine, it led to lots of swapping
> and high system times:
>
>  scheduling 2          :   4.14 ( 2%) usr 239.38 (22%) sys 277.61 (20%) wall
>  machine dep reorg     :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
>  reorder blocks        :  24.00 (12%) usr  42.49 ( 4%) sys  80.78 ( 6%) wall
>  shorten branches      :   0.44 ( 0%) usr   1.01 ( 0%) sys   1.51 ( 0%) wall
>  final                 :   4.36 ( 2%) usr 142.77 (13%) sys 154.28 (11%) wall

Ugh.  second scheduling and final hit the swap fairly serious.  And those
are after the last reorder_basic_blocks() call if I look correctly.  I
guess they are hit by the now expanded CFG, and am not sure if much can be
done, except throttling scheduling in/over those ugly blocks.

Or the duplication of the comp-goto block can be deferred even more, but
I'm not sure, how feasible this is.


Ciao,
Michael.



More information about the Gcc-patches mailing list