https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #12) > (In reply to vries from comment #11) > > The ipa-pta solution no longer works. In 4.6, we had: > > ... > > # USE = anything > > # CLB = anything > > GOMP_parallel_startD.1048 (main._omp_fn.0D.1472, &.omp_data_o.1D.1484, 0); > > # USE = anything > > # CLB = anything > > main._omp_fn.0D.1472 (&.omp_data_o.1D.1484); > > # USE = anything > > # CLB = anything > > GOMP_parallel_endD.1049 (); > > ... > > > > On trunk, we have now: > > ... > > # USE = anything > > # CLB = anything > > GOMP_parallelD.1345 (main._omp_fn.0D.1844, &.omp_data_o.1D.1856, 0, 0); > > ... > > > > So there's no longer a path in the call graph from main to main._omp_fn. > > Perhaps a dummy body for GOMP_parallel could fix that. > > Hm? The IPA PTA "solution" was to tell IPA PTA that the call to > GOMP_parallel > doesn't make .omp_data_o escape. > > The attached patch doesn't work because it only patches GOMP_parallel_start, > not GOMP_parallel. > > Of course it would even better to teach IPA PTA that GOMP_parallel > is really invoking main._omp_fn.0 with a &.omp_data_o.1 argument. > > How many different ways of IL do we get doing this kind of indirect > function invocations? Other IPA propagators like IPA-CP probably also would like to know this. I see various builtins taking a OMPFN argument in omp-builtins.def. If we assume the GOMP runtime itself is "transparent" then do we know how the builtins end up calling the actual implementation function?