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