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!) Thanks, Richard.
