On Sun, 2006-01-15 at 21:49 +0100, Richard Guenther wrote: > 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'm still not convinced it's worth it, but apparently Diego was :). Except for tramp code, i've never really seen code that heavily uses small arrays with constant index accesses. It'd be nice if you made it not make SFT's if we don't have at least two different constant index accesses to any array, since we'll just be wasting time.
