https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 6 Dec 2024, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922 > > --- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Andrew Pinski from comment #6) > > (In reply to Andrew Pinski from comment #5) > > > (In reply to Andrew Pinski from comment #4) > > > > For me targetting aarch64, the peak memory is over 26G and it is taking > > > > over > > > > an hour. > > > > -O2 Finally finished for me: > > (--enable-checking=yes but -fno-checking): > > df reaching defs :2245.15 ( 47%) 0 ( 0%) > > df live regs : 457.94 ( 10%) 0 ( 0%) > > df live&initialized regs : 221.75 ( 5%) 0 ( 0%) > > scheduling : 468.28 ( 10%) 13M ( 0%) > > With -fno-fold-mem-offsets: > df reaching defs : 22.39 ( 1%) 0 ( 0%) > df live regs : 461.52 ( 18%) 0 ( 0%) > df live&initialized regs : 223.56 ( 9%) 0 ( 0%) > scheduling : 467.40 ( 18%) 13M ( 0%) > > So it is better but still pretty bad otherwise. -ftime-report -ftime-report-details will tell you which pass did those DF ops (iff the pass has a timevar...)
