Bug 95084 - [11/12/13/14 Regression] code sinking prevents if-conversion
Summary: [11/12/13/14 Regression] code sinking prevents if-conversion
Status: RESOLVED DUPLICATE of bug 92335
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 11.0
: P2 normal
Target Milestone: 11.5
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
: 106217 (view as bug list)
Depends on:
Blocks: spec
  Show dependency treegraph
 
Reported: 2020-05-12 13:46 UTC by Richard Biener
Modified: 2023-08-04 17:26 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2022-01-31 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2020-05-12 13:46:09 UTC
There's a pass ordering issue between the sink pass and tree-if-conv, if conversion for vectorization.  When sink sinks a possibly trapping operation
to a place that is only conditionally executed if-conversion fails which
results in failed vectorization.  This can be seen with
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545588.html applied
for gcc.dg/vect/pr56541.c (and it's ifcvt counterpart gcc.dg/tree-ssa/ifc-pr56541.c).  But I've also seen this in other context.

Here

  iftmp.2_17 = rR_19 < rL_20 ? rR_19 : rL_20;
  iftmp.3_3 = rR_19 < rL_20 ? rL_20 : rR_19;
  if (iftmp.3_3 > 0.0)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 4> :

  <bb 5> :
  # iftmp.4_14 = PHI <iftmp.2_17(3), 1.5e+2(4)>
  if (iftmp.4_14 > 0.0)

becomes

  iftmp.3_3 = rR_17 < rL_18 ? rL_18 : rR_17;
  if (iftmp.3_3 > 0.0)
    goto <bb 4>; [59.00%]
  else
    goto <bb 9>; [41.00%]

  <bb 9> [local count: 435831803]:
  goto <bb 6>; [100.00%]

  <bb 4> [local count: 627172605]:
  iftmp.2_15 = rR_17 < rL_18 ? rR_17 : rL_18;
  if (iftmp.2_15 > 0.0)

and the now conditionally executed FP comparison can trap.
Comment 1 Richard Sandiford 2022-01-31 15:24:36 UTC
Yeah.  I'm seeing this as a GCC 11/12 regression on:

float f(float *x, float *y) {
  float res = 0;
  for (int i = 0; i < 100; ++i) {
    float next = __builtin_sqrtf (y[i]);
    res += x[i] < 100 ? x[i] : next;
  }
  return res;
}

which is cut down from HACCmk.  Previously we could vectorise
the loop for Advanced SIMD at -Ofast, whereas now we require
-Ofast -fno-tree-sink.  (SVE can vectorise it both ways due
to predicated loads.)
Comment 2 Richard Biener 2022-02-01 07:31:28 UTC
Note the issue is older but there are some cases where sink didn't do its job that have been fixed meanwhile.

For GCC 12 we have an additional (albeit quite late) sinking pass, so one option might be to tame down early sinking for possibly trapping operations in loops that look like they could be vectorized (similar how we tame PRE).

I think the only loop pass affected by not sinking might be unswitching which
could get less favorable costs due to the need to duplicate the not sunk stmts.

At least I cannot think of a way to preserve the conditional non-trappingness on the ref after sinking it.
Comment 3 Richard Biener 2022-04-21 07:47:58 UTC
GCC 11.3 is being released, retargeting bugs to GCC 11.4.
Comment 4 Andrew Pinski 2022-07-06 21:17:14 UTC
*** Bug 106217 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2023-05-29 10:02:51 UTC
GCC 11.4 is being released, retargeting bugs to GCC 11.5.
Comment 6 Andrew Pinski 2023-08-04 17:26:46 UTC
This was fixed by the patch which fixed PR 92335 and since that is still open as a regression like this one I am going to close this one as a dup of bug 92335 and they are exactly the same issue even.

*** This bug has been marked as a duplicate of bug 92335 ***