https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90488
Bug ID: 90488
Summary: OpenACC Profiling Interface: callbacks from the
OpenACC implementation into user code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openacc, wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, vries at gcc dot gnu.org
Target Milestone: ---
As a short summary, the OpenACC Profiling Interface (soon to be committed to
trunk) causes for callbacks from the OpenACC implementation into user code.
For example:
#include <acc_prof.h>
static int ev_count;
static void cb_any_event (acc_prof_info *prof_info, acc_event_info
*event_info, acc_api_info *api_info)
{
__builtin_printf ("E");
++ev_count;
}
int main()
{
acc_prof_register (acc_ev_compute_construct_start, cb_any_event,
acc_reg);
ev_count = 0;
#pragma acc parallel
// Callback into 'cb_any_event' for 'acc_ev_compute_construct_start'.
{
}
__builtin_printf ("%d\n", ev_count);
return 0;
}
With optimizations enabled, this will print "E0" instead of the expected "E1",
meaning that the callback function 'cb_any_event' does get invoked, but the
compiler still thinks that this one cannot possibly change the value of
'ev_count'.
I suppose this is due to the 'GOACC_parallel_keyed' function (implementing the
OpenACC 'parallel' construct) being tagged as some kind of "leaf" function?
It's not in 'gcc/omp-builtins.def', however. But indeed, if in
'gcc/tree-ssa-structalias.c' I disable the special handling for
'BUILT_IN_GOACC_PARALLEL' in function 'find_func_aliases_for_builtin_call' or
'ipa_pta_execute', then this example behaves as expected. (Tom added this
IPA-PTA handling in late 2015; CCed, in case you have any input.)
I would then assume that this is not a problem in the common case that the
OpenACC Profiling Interface "library" (the part that is providing and
registering the callbacks) is distinct (separate translation unit) from the
actual user code (containing the OpenACC directives).
For the same reason, we'll probably also have to remove the "nothrow" attribute
for all these builtins/functions (that can cause callbacks to happen)? (Given
that a callback may "throw", as I understand this?)
All this will probably have adverse effects on compiler optimizations? :-(
