https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Thanks for the report, and initial analysis.
Unless there is an OpenACC 'bind' clause involved (also 'nohost' clause?)
(which are not yet implemented, so not relevant in this discussion), it is
permissible (and worthwhile for the usual reasons) to inline such functions
into one another, given proper nesting of OpenACC levels of parallelism. The
latter is enforced by construction, by detecting improper caller/callee
combinations (for example, trying to call a 'gang' routine from a 'vector'
context).
By construction, 'IFN_UNIQUE' etc. can only appear in 'oacc function'
functions.
There are 'oacc function' functions that do not contain 'IFN_UNIQUE' etc. (for
example, 'seq' functions, such as math library functions), but which might
still benefit from inlining.
I suppose it is fine to do inlining if the outer function will then be handled
by 'oaccdevlow'.
And, I suppose it will be reasonable to forbid inlining of 'oacc function'
functions into non-'oacc function' functions, because in that case you're not
applying any OpenACC parallelism anyway, at least for a backportable ICE fix,
then later possibly more logic added to allow that.
That will probably be reasonably simple to implement; I'll give it some further
thought, and testing.
