https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com,
| |jakub at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
HJ, you added remove_partial_avx_dependency - it adds loads of DF problems
but during its execution it does not seem to use anything but doing
df_insn_rescan. I'm not too familiar with DF so I assume calling
df_analyze is necessary to mark insns for rescan (I'd assume _not_ calling
df_analyze but only setting defered-rescan and not processing defered
rescans in a pass not needing DF at all should work?! Or even defered
rescan is default on in that case).
Besides this the pass ups memory use from 2GB to 7GB and memory use doesn't
drop so there's sth fishy going on here.
I'm testing the obvious remove of
df_chain_add_problem (DF_DU_CHAIN | DF_UD_CHAIN);
df_md_add_problem ();
which was likely copied from STV (where I removed adding MD), but STV
_does_ at least use DF and exercises use/def chains.
I'm also not sure altering the CFG is the very best thing to do when
DF is active (and doing that with MD or DU/UD might cause interesting
unknown issues I guess). At least with not adding MD or DU/UD_CHAIN
the "leak" is gone. Richard or Jakub may know more here, esp. whether
we can elide the df_analyze completely (I hope we can!). Even
DF_LIVE and LR alone are a major hog on this testcase (but at least
stay within 2GB of memory while RD tops at 7GB).
