[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?

["jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Feng Xue from comment #1)
> 
> OK. I does missed something. Here we could not hold assumption that
> ipcp_decision_stage() only sees raw cgraph node, since sometime in the
> future some new ipa pass may be added prior to ipa-cp, and this pass
> introduces clone node.

Right, initially IPA-SRA was developed as a pass before IPA-CP and it
may well be that we decide to swap the order again.

> 
> However, there is a questionable point about the code snippet
> 
> 	  if (!node->can_change_signature
> 	      || old_adj->op != IPA_PARAM_OP_COPY
> 	      || (!known_csts[old_adj->base_index]
> 		  && ipa_is_param_used (info, old_adj->base_index)))
> 
> In ipa-cp, known_csts is for the node, has no relation to the node's origin
> node, but here it is accessed via index of the latter (old_adj->base_index),
> will this cause out-of-bound error?

I think the code is correct. Assume IPA-SRA running before IPA-CP, and
we're compiling a function with two argument, with indices 0 and 1.

Analysis phases of both passes run before the IPA (WPA) phases of
either.  This is important to keep in mind.

IPA SRA removes the first one with index zero as useless, IPA-CP wants
to remove the second one with index 1, possibly because it is constant
everywhere.  In oder to that it has to combine the pre-existing
adjustments with its own changes.

Before create_specialized_node, the pass checks whether previous
passes did not kill some parameters and stops caring about them, but
it does not re-index anything, all lattices, jump functions,
everything, still keep their positions (and thus indices) they got in
the analysis phase.

Then create_specialized_node hits this loop.  For i=0 encounters an
old_adj element that actually describes the parameter which originally
had index 1.  The pass looks up in base_index what the original
(pre-IPA) index of the parameter was (1) and uses those to look up in
its own structures whether it wants to remove it or not.

Bounds should be always OK, base_index should never be greater than
the original pre-IPA number of parameters (-1) and known_csts should
always have just as many parameters.

Does that make sense?