https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #46 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 50162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50162&action=edit df-live on demand So I did the experiment to turn off DF_LIVE as permanent like we do for -O1. w/o permanent DF_LIVE: df reaching defs : 23.36 ( 7%) 0.13 ( 4%) 23.84 ( 7%) 0 ( 0%) df live regs : 45.56 ( 14%) 0.09 ( 3%) 45.61 ( 14%) 0 ( 0%) df live&initialized regs : 19.42 ( 6%) 0.11 ( 3%) 19.49 ( 6%) 0 ( 0%) TOTAL : 314.61 3.19 317.93 2538M w/ permanent DF_LIVE: df reaching defs : 23.53 ( 7%) 0.01 ( 0%) 23.45 ( 7%) 0 ( 0%) df live regs : 44.95 ( 14%) 0.09 ( 3%) 45.13 ( 14%) 0 ( 0%) df live&initialized regs : 19.70 ( 6%) 0.08 ( 3%) 19.68 ( 6%) 0 ( 0%) TOTAL : 313.83 2.94 316.92 2538M which doesn't seem to be much of a difference (but there's some observable times with less memory use since live consumes ~400MB in bitmaps). It should be noted that the passes that add DF_LIVE anyway (and thus on-demand at -O1) are all enabled by default at -O1. Which makes me question this design decision even more. In principle keeping DF_LIVE from invariant motion to doloop might make sense (unroll loops isn't enabled by default, but also not all targets have doloop). Maybe even starting from ifcvt1. I've attached the patch used for the experiment.
