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

            Bug ID: 102443
           Summary: IPA CP and/or IPA VRP into OpenMP/OpenACC outlined
                    functions
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

If IPA CP or IPA VRP can handle
struct whatever x;
x.fld1 = 123; // for IPA CP
if (y > 123 || y < 42) __builtin_unreachable ();
x.fld2 = y; // for IPA VRP 
foo (&x);
and foo using x->fld1 or x->fld2 shortly after start, then it shouldn't be far
from handling also propagation into OpenMP/OpenACC regions, but there is one
big obstackle.
As can be seen in:
void
foo (void)
{
  int x = 5;
  int vla[x];
  __builtin_memset (vla, 0, sizeof (vla));
  #pragma omp parallel firstprivate (x)
  {
    x++;
  }
  #pragma omp teams firstprivate (x)
  {
    x++;
  }
  #pragma omp task firstprivate (x)
  {
    x++;
  }
  #pragma omp task firstprivate (x) firstprivate (vla)
  {
    x++;
    vla[0]++;
  }
  #pragma omp taskwait
  #pragma omp target firstprivate (x)
  {
    x++;
  }
}
with -O2 -fopenmp, the outlined functions are never called directly, but
through a __builtin_GOMP_* function.  So, would it be possible for IPA CP/VRP
purposes (but not for inlining etc.) treat e.g.
__builtin_GOMP_parallel (fn1, &struct1obj, ...)
as if it was fn1 (&struct1obj) call?
Similarly for
__builtin_GOMP_teams_reg (fn2, &struct2obj, ...)
as if it was fn2 (&struct2obj), or
__builtin_GOMP_task (fn3, &struct3obj, NULL, ...)
as if it was fn3 (&struct3obj).  __builtin_GOMP_task has another case,
__builtin_GOMP_task (fn4, &struct4obj, cpyfn4, ...)
needs to be treated as 
{
struct ... temp; // different from type of struct4obj
cpyfn4 (&temp, &struct4obj);
fn4 (&temp);
}
Finally, __builtin_GOMP_target_ext is more complicated, but if we handle only
firstprivate propagation perhaps still doable.  And OpenACC has its own
builtins as well.
Now, because all the structs are compiler generated, omp-low.c could if it
would be beneficial to IPA propagation add some magic attributes (with spaces
in names) to certain fields (e.g. those that act as read-only with the body of
function, where value is never stored back and therefore it is ok to e.g.
replace all reads from that field with constants or annotate all reads from
that field into SSA_NAME with VRP data.
For IPA CP, at least for target one would need to limit to propagation of
INTEGER_CSTs/REAL_CSTs etc., but avoid propagation of static variable addresses
etc.

I'm unfortunately not very familiar with the jump functions/ipa propagation and
how to achieve the above.

Reply via email to