On 1/15/06, Tobias Schlüter <[EMAIL PROTECTED]> wrote: > > In looking at compiles times, I missed looking at memory usage: > > Dominique Dhumieres wrote: > > On an AMD, the 20060105 build gives > > > > tree SSA rewrite : 0.45 ( 2%) usr 0.02 ( 5%) sys 0.36 ( 2%) > > wall 35265 kB (27%) ggc > > tree SSA incremental : 0.71 ( 4%) usr 0.02 ( 5%) sys 0.77 ( 4%) > > wall 6145 kB ( 5%) ggc > > tree operand scan : 0.44 ( 2%) usr 0.07 (18%) sys 0.55 ( 3%) > > wall 17385 kB (13%) ggc > > expand : 0.39 ( 2%) usr 0.00 ( 0%) sys 0.46 ( 2%) > > wall 9703 kB ( 8%) ggc > > TOTAL : 19.26 0.40 19.91 > > 129144 kB > > 20060106: > > tree SSA rewrite : 0.93 ( 3%) usr 0.03 ( 8%) sys 1.08 ( 3%) > > wall 65009 kB (33%) ggc > > tree SSA incremental : 1.84 ( 5%) usr 0.02 ( 5%) sys 1.87 ( 5%) > > wall 13262 kB ( 7%) ggc > > tree operand scan : 0.88 ( 3%) usr 0.05 (13%) sys 0.97 ( 3%) > > wall 29929 kB (15%) ggc > > expand : 0.97 ( 3%) usr 0.01 ( 3%) sys 1.01 ( 3%) > > wall 13943 kB ( 7%) ggc > > TOTAL : 33.82 0.38 34.64 > > 194932 kB > > An increase by > 50%. Here and before I extracted the numbers from your > compilations of induct.f90. > > It looks like we're generating significantly more trees now, which would of > course explain the increase in time spent checking.
I guess the fix for PR tree-optimization/22555 could make some difference if fortran uses a lot of structures with embedded arrays. Basically this enables decomposing these structures for aliasing purposes and should generate better code. I suggest to do a comparison with --disable-checking and if there's a significant regression, file a PR about it. At least it would be nice to know what exactly is going on. You can also try -fno-tree-salias and see if this helps compile time. Richard.
