https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> It's not only "slow", it also produces a gigantic executable, the .original
> dump was 7.1GB when I stopped the compilation ...
Well, original dump for deeply nested SAVE_EXPRs is pretty unusable, even when
the actual trees are fairly small, because it prints each SAVE_EXPR in full.
If we wanted to avoid that, we'd need to use during the printing some hash
table on which SAVE_EXPRs we have printed already and print some id for them
and print just that id rather than full content next time we see it. Or
perhaps trigger that behavior when we see deeper SAVE_EXPR nesting.
> The culprit is c_genericize calling c_genericize_control_r which must
> somehow do the ubsan instrumentation as well.
As Marek said, on the C++ FE side this is handled by cp-gimplify.cc using a
pset on its own and not trying to genericize a control stmt which has been
handled already (e.g. when seeing it again in another SAVE_EXPR), or even
SAVE_EXPRs that have been handled already.
So, adding another pset that would be used also for C++ would be a waste.
Now, the C FE in c-gimplify.cc has:
walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl),
c_genericize_control_r, NULL);
so it effectively already creates a pset.
Thus, I think we should replace this walk_tree_without_duplicates with a new
pset + walk_tree, pass &pset twice - as pset and data and in
c_genericize_control_r don't walk again what we've already walked.
which
