[Bug target/105275] [12/13/14 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

[law at gcc dot gnu.org via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug target/105275] [12/13/14 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

[Bug target/105275] [12/13/14 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Since this was a costing change I wonder if we identified the code change
responsible and thus have a testcase?  I realize that for maximum assurance
one would need to have a debug counter for switching the patch on/off to
have it apply more selectively (possibly per SLP attempt rather than
per cost hook invocation which would be even more tricky to do).

Feeding another parameter to the hook via a new flag in the vinfo might
be possible (and set that from a dbg_cnt call) for example.