PATCH: [gcc3.5 improvement branch] Very Simple constant propagation
Geoff Keating
geoffk@apple.com
Tue Feb 3 19:47:00 GMT 2004
On Feb 3, 2004, at 8:19 AM, Jan Hubicka wrote:
>>
>> On Mon, 2 Feb 2004, Geoff Keating wrote:
>>> To match Caroline's results, you should use --enable-intermodule and
>>> -O3, not just a regular bootstrap.
>>>
>>> The concern is compile-time performance on large-to-very-large
>>> functions, like those created by intermodule inlining in SPEC.
>>
>> Hi Geoff,
>>
>> I'm still not seeing it. Unfortunately, an --enable-intermodule
>> bootstrap with BOOT_CFLAGS="-O3" currently fails for mainline
>> during stage2 on i686-pc-linux-gnu due to "symbol already defined"
>> errors from the assembler. However, it is possible to analyse
>> the behaviour of stage1/cc1 prior to this fatal failure:
>>
>> Execution times (seconds)
>> garbage collection : 60.92 ( 4%) usr 0.11 ( 1%) sys 61.03 (
>> 4%) wall
>> callgraph construction: 1.90 ( 0%) usr 0.03 ( 0%) sys 1.93 (
>> 0%) wall
>> callgraph optimization: 0.26 ( 0%) usr 0.03 ( 0%) sys 0.29 (
>> 0%) wall
>> cfg construction : 3.15 ( 0%) usr 0.16 ( 1%) sys 3.28 (
>> 0%) wall
>> cfg cleanup : 15.10 ( 1%) usr 0.20 ( 1%) sys 15.91 (
>> 1%) wall
>> CFG verifier : 18.63 ( 1%) usr 0.05 ( 0%) sys 18.02 (
>> 1%) wall
>> trivially dead code : 9.02 ( 1%) usr 0.01 ( 0%) sys 8.51 (
>> 1%) wall
>> life analysis : 19.47 ( 1%) usr 0.02 ( 0%) sys 20.04 (
>> 1%) wall
>> life info update : 15.59 ( 1%) usr 0.02 ( 0%) sys 15.45 (
>> 1%) wall
>> alias analysis : 7.65 ( 1%) usr 0.01 ( 0%) sys 7.91 (
>> 1%) wall
>> register scan : 6.17 ( 0%) usr 0.02 ( 0%) sys 6.25 (
>> 0%) wall
>> rebuild jump labels : 2.28 ( 0%) usr 0.00 ( 0%) sys 2.14 (
>> 0%) wall
>> preprocessing : 9.39 ( 1%) usr 2.41 (17%) sys 12.80 (
>> 1%) wall
>> lexical analysis : 5.67 ( 0%) usr 3.65 (26%) sys 9.27 (
>> 1%) wall
>> parser : 881.58 (63%) usr 2.83 (20%) sys 884.32
>> (62%) wall
>
> Geoff,
> I see I am not only one who get inadequately large amount of time spent
> in parser with intermodule. All the times goes into the final merging
> of declarations across modules that is implemented with quadratic
> complexity. Do you think there is some chance to see this cut down to
> resonable times?
Why do you think it's quadratic? It looks like two loops over all
declarations to me.
> I am also getting internal compiler error in dwarf2out later, but I've
> failed to produce some testcase for this :(
Testcases are very hard for this stuff, I recommend gdb.
--
Geoff Keating <geoffk@apple.com>
More information about the Gcc-patches
mailing list