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

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

[fxue at os dot amperecomputing.com]

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

            Bug ID: 104377
           Summary: Unreachable code in create_specialized_node of
                    ipa-prop.c?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxue at os dot amperecomputing.com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For function create_specialized_node(), the "node" to operated on seems always
to be an original cgraph node, never a clone node. From call graph related to
the function, we know that ipcp_decision_stage () only passes raw cgraph node
downwards to its callees. Then, "node" reaching create_specialized_node() would
not be a clone, so the code enclosed by "if (old_adjustments)" might be of no
use. But I am not sure sure if there is some thing that I missed.

ipcp_driver
 |
 '--> ipcp_decision_stage
       |
       '--> decide_whether_version_node
             |
             |--> decide_about_value
             |     |
             '-----'--> create_specialized_node

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

[fxue at os dot amperecomputing.com]

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

--- Comment #1 from Feng Xue <fxue at os dot amperecomputing.com> ---
(In reply to Feng Xue from comment #0)
> For function create_specialized_node(), the "node" to operated on seems
> always to be an original cgraph node, never a clone node. From call graph
> related to the function, we know that ipcp_decision_stage () only passes raw
> cgraph node downwards to its callees. Then, "node" reaching
> create_specialized_node() would not be a clone, so the code enclosed by "if
> (old_adjustments)" might be of no use. But I am not sure sure if there is
> some thing that I missed.
> 
> ipcp_driver
>  |
>  '--> ipcp_decision_stage
>        |
>        '--> decide_whether_version_node
>              |
>              |--> decide_about_value
>              |     |
>              '-----'--> create_specialized_node


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.

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?

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

[jamborm at gcc dot 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?

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

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
By the way, it would be good to invent some (slightly?) more intuitive API for
ipa_param_adjustments adjustments, merging and similar operations.  I simply
left it for later when I hoped I would have a better idea what API would be
best for the code that needs it.

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

[fxue at os dot amperecomputing.com]

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

--- Comment #4 from Feng Xue <fxue at os dot amperecomputing.com> ---
(In reply to Martin Jambor from comment #2)
> (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?

Yes. Thanks for your explanation.