[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

["hubicka at kam dot mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227

--- Comment #8 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
> 
> --- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> ---
> (In reply to hubicka from comment #5)
> > > I like the idea of transformation phases better than putting
> > > everything into tree-inline (and by extension ipa-param-manipulation)
> > > but perhaps we have to do aggregate constant replacements there too?
> > 
> > So the situation is that we inline call A->B (where both A and B are
> > clones of the main function) and while we place uses of the constant
> > parmater in A we miss replacement in B because transform is not run on
> > it.
> 
> No, we miss it everywhere, even in A (see that the code above is from
> BB 2) or probably also without any cloning whatsoever. This happens
> when IPA-SRA does its thing on the same parameter on which IPA-CP
> decided to propagate aggregate constants.
> 
> In the IPA analysis stage (which creates the virtual clones), IPA-CP
> runs before IPA-SRA.  But in the transformation phase, it is
> apparently the other way round - well, not exactly, IPA-SRA does not
> formally have a transformation phase, it happens as part of
> tree_function_versioning, but the effect is the same.

OK, so the problem is that we don't do ipa-sra changes "in place" as a
well behaved transform pass but it i merged into versioning code while
ipa-cp is the other way around.  So one fix would be alo to make ipa-cp
understand that changes to signature happened and update its summary
just like we do for modref?

We will need it also for ...
> 
> > 
> > I think proper solution here (discussed also few years ago) is to keep
> > the optimization summaries and teach value numbering to look up the
> > constant from the summary.
> > 
> 
> Yes, but this is another (but different) problem that we probably also
> should try to solve now.

... fixing this problem properly.
I just loked into thi again and we already have code that preserves
propagates bits on pointer parmeters (since these do not have value
ranges). Same way we need to preserve the known partial aggregates and
hook it up into sccvn's vn_reference_lookup_2 and _3.

Honza