]> git.ipfire.org Git - thirdparty/gcc.git/commit
fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284]
authorJakub Jelinek <jakub@redhat.com>
Sat, 9 Mar 2024 12:04:26 +0000 (13:04 +0100)
committerJakub Jelinek <jakub@redhat.com>
Sat, 9 Mar 2024 12:04:26 +0000 (13:04 +0100)
commit3e3e4156a5f93e6d62101594ca6660ee9ce9c10e
treeee47e67a17ab574273fc893e6fa6e2cbb9132b85
parent42cd49aa48c7ca99e8d5e91ce582d41fdb75f3fc
fwprop: Restore previous behavior for forward propagation of RTL with MEMs [PR114284]

Before the recent PR111267 r14-8319 fwprop changes, fwprop would never try
to propagate what was not considered PROFITABLE, where the profitable part
actually was partly about profitability, partly about very good reasons
not to actually propagate and partly for cases where propagation is
completely incorrect.
In particular, classify_result has:
  /* Allow (subreg (mem)) -> (mem) simplifications with the following
     exceptions:
     1) Propagating (mem)s into multiple uses is not profitable.
     2) Propagating (mem)s across EBBs may not be profitable if the source EBB
        runs less frequently.
     3) Propagating (mem)s into paradoxical (subreg)s is not profitable.
     4) Creating new (mem/v)s is not correct, since DCE will not remove the old
        ones.  */
  if (single_use_p
      && single_ebb_p
      && SUBREG_P (old_rtx)
      && !paradoxical_subreg_p (old_rtx)
      && MEM_P (new_rtx)
      && !MEM_VOLATILE_P (new_rtx))
    return PROFITABLE;
and didn't mark any other MEM_P (new_rtx) or rtxes which contain
a MEM in its subrtxes as PROFITABLE.  Now, since r14-8319 profitable_p
method has been renamed to likely_profitable_p and has just a minor role.
Now, rule 4) above is something that isn't about profitability, but about
correct behavior, if you propagate mem/v, the code is miscompiled.
This particular case has been fixed elsewhere by Haochen in r14-9379.
But I think even the 1) and 2) and maybe 3) are a strong don't do it,
don't rely solely on rtx costs, increasing the number of loads of the same
memory, even when cached, is undesirable, canceling load hoisting can
be undesirable as well.

So, the following patch restores previous behavior of src contains any MEMs,
in that case likely_profitable_p () is taken as the old profitable_p ()
as a requirement rather than just a hint.  For propagation of something
which doesn't load from memory this keeps the r14-8319 behavior.

2024-03-09  Jakub Jelinek  <jakub@redhat.com>

PR target/114284
* fwprop.cc (try_fwprop_subst_pattern): Don't propagate
src containing MEMs unless prop.likely_profitable_p ().
gcc/fwprop.cc