On Fri, 11 Dec 2015, Tom de Vries wrote:
Hi,
while testing the oacc kernels patch series on top of trunk, using the optimal
handling of BUILTIN_IN_GOACC_PARALLEL in fipa-pta I ran into a failure where
the stores to the omp_data_sizes array were removed by dse.
The call bb in the failing testcase normally looks like this:
...
<bb 3>:
.omp_data_arr.10.D.2550 = c.2_18;
.omp_data_arr.10.c = &c;
.omp_data_arr.10.D.2553 = b.1_15;
.omp_data_arr.10.b = &b;
.omp_data_arr.10.D.2556 = a.0_11;
.omp_data_arr.10.a = &a;
D.2572 = n_6(D);
.omp_data_arr.10.n = &D.2572;
.omp_data_sizes.11[0] = _8;
.omp_data_sizes.11[1] = 0;
.omp_data_sizes.11[2] = _8;
.omp_data_sizes.11[3] = 0;
.omp_data_sizes.11[4] = _8;
.omp_data_sizes.11[5] = 0;
.omp_data_sizes.11[6] = 4;
__builtin_GOACC_parallel_keyed (-1, foo._omp_fn.0, 7,
&.omp_data_arr.10,
&.omp_data_sizes.11,
&.omp_data_kinds.12, 0);
...
Dse removed the stores, because omp_data_sizes was not marked as a used by
__builtin_GOACC_parallel_keyed.
We pretend in fipa-pta that __builtin_GOACC_parallel_keyed is never called,
and instead handle the call foo._omp_fn.0 (&.omp_data_arr.10). That means the
use of omp_data_sizes by __builtin_GOACC_parallel_keyed is ignored.
This patch fixes that (for both sizes and kinds arrays), as confirmed with a
test run of target-libgomp c.exp on the accelerator.
OK for stage3 if bootstrap and reg-test succeeds?
Ok, though techincally they are used by the OMP runtime (but this we
could only represent by letting them escape). I wonder what can of
worms we'd open if you LTO the OMP runtime in ... (and thus
builtins map to real functions!)