[Bug tree-optimization/97008] New: [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[Bug tree-optimization/97008] New: [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[vries at gcc dot gnu.org]

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

            Bug ID: 97008
           Summary: [openacc] Remove invariant that IFN_UNIQUE is last
                    stmt in bb
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ spin-off of PR97000 comment 9. ]

There's an invariant that says IFN_UNIQUE needs to be the last stmt in a bb.
The rationale given is that it speeds up lookup.

This is somewhat of a hack, and potentially inhibits various
optimizations/cleanups.

So, can we drop this invariant?

This patch (PR97000 comment 2) is probably needed, possibly more.

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Where's this property used?  grepping finds searches in omp-offload but those
all(?) search the whole instruction stream.

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Where's this property used?  grepping finds searches in omp-offload but those
> all(?) search the whole instruction stream.

In ignore_bb_p in gcc/tracer.c, see PR97000 comment 2.

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I see.  Wonder if it that shouldn't be in can_duplicate_block_p though (where
the GIMPLE variant doesn't do anything, so a full stmt walk would be
expensive).

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I did a libgomp test run with commit f96b6328fa7 "[tree-optimization] Don't
clear ctrl-altering flag for IFN_UNIQUE" reverted, and with this patch:
...
diff --git a/gcc/tracer.c b/gcc/tracer.c
index 0f69b335b8c..3a4403d92b1 100644
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -93,11 +93,15 @@ can_duplicate_insn_p (gimple *g)
      The IFN_GOMP_SIMT_VOTE_ANY is currently part of such a group,
      so the same holds there, but it could be argued that the
      IFN_GOMP_SIMT_VOTE_ANY could be generated after that group,
-     in which case it could be duplicated.  */
+     in which case it could be duplicated.
+     An IFN_UNIQUE call must be duplicated as part of its group,
+     or not at all.  */
   if (is_gimple_call (g)
       && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
          || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
-         || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)))
+         || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
+         || (gimple_call_internal_p (g)
+             && gimple_call_internal_unique_p (g))))
     return false;

   return true;
@@ -117,8 +121,6 @@ can_duplicate_bb_no_insn_iter_p (const_basic_block bb)
       if (gimple_code (g) == GIMPLE_TRANSACTION)
        return false;

-      /* An IFN_UNIQUE call must be duplicated as part of its group,
-        or not at all.  */
       if (is_gimple_call (g)
          && gimple_call_internal_p (g)
          && gimple_call_internal_unique_p (g))
...

No issues found.

[Bug tree-optimization/97008] [openacc] Remove invariant that IFN_UNIQUE is last stmt in bb

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
The openacc machinery is the only user of IFN_UNIQUE.

Thomas, as openacc maintainer, is this change ok for you, or are reasons why
you want to keep the IFN_UNIQUE as last stmt of the BB?