Bug 102443 - IPA CP and/or IPA VRP into OpenMP/OpenACC outlined functions
Summary: IPA CP and/or IPA VRP into OpenMP/OpenACC outlined functions
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: 12.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization, openacc, openmp
Depends on:
Blocks:
 
Reported: 2021-09-22 08:09 UTC by Jakub Jelinek
Modified: 2021-09-22 12:27 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2021-09-22 08:09:14 UTC
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.