On Thu, Apr 30, 2020 at 08:24:02AM +0200, Richard Biener wrote:
> On Wed, Apr 29, 2020 at 5:05 PM Tobias Burnus <tob...@codesourcery.com> wrote:
> > was a bit on the backburner but I now digged again.
> > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
> >
> > The problem is a generated static array variable in the
> > device function:
> > static integer(kind=4) A.12[3] = {1, 2, 3};
> > used as
> > _26 = A.12[S.13_67];
> >
> > With -ftree-pre, the expressions using _26 now directly use
> > the value (1, 2 and 3). It seems as if the variable A.12 is
> > eliminated before writing to LTO but the usage (A.12[S.…])
> > is not – at least it still appears in the device dumps.
> >
> > Maybe it is also related to something else, but crucial is
> > the -ftree-pre on the host side; the optimization level on
> > the device lto1 side is irrelevant.
>
> IIRC there was a bugreport similar to this where offload
> variables were computed "early" instead of at the point
> of streaming.
>
> It's obvious that the offload "part" use is not reflected in
> the non-offloat "part" IL (like via a function call parameter
> or so), so I assume this is a local static in a function
> we simply compile twice (but did not actually clone),
> once for each offloat target and once for the host. So it's
> likely the above issue.
I'll try to do something about that early in stage1 and
eventually backport, we need to follow OpenMP rules anyway and
those require auto-discovery of referenced functions (if they are
definitions rather than just declarations), and similarly in
some cases for variables. And the same code then could, if something
shouldn't be marked for offloading by the standard, complain loudly rather
than leaving it up for later (lto1 of the offloading compiler).
Jakub
