https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> --- Still, the interaction between IPA-CP and IPA-SRA is bad here. Just looking at the optimized dump, one of the "specialized functions" starts with: <bb 2> [local count: 62767467]: # DEBUG D#203 s=> row # DEBUG row => D#203 _2 = (long int) ISRA.10821_938(D); where the ISRA param contains the constant we wanted to specialize for... making the clones worse than useless. >From the IPA-CP ltrans dumps it is clear that the transformation phase of IPA-CP considers the first parameter dead and so does not perform the substitutions even though the parameter is replaced only by a "subsequent" pass. The infrastructure invokes the transform function on node digits_2.constprop.isra/157 (note the isra) which has already been modified by the subsequent pass (when it was cloned). 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?
