https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 24 Nov 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 > > --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > There should be no duplication except for vars mentioned in the clauses on > OpenMP constructs (explicit or implicit). So, vars declared outside of the > region and referenced inside of the region are either implicitly or explicitly > shared/privatized/mapped etc. and vars defined inside of the region are just > moved to the new outlined function. We move there the whole BLOCK subtree > that > is fully contained within the region and the vars too. Yes, that's what I'm seeing with OMP but I'm not seeing that with autopar. Ah, it looks like autopar identifies the "local" as to be globalized in eliminate_local_variables_stmt. So it would need to somehow detect whether a variable "belongs" to the loop we are parallelizing. Which means detecting whether a BLOCK belongs to a loop? I guess OMP expansion has an easier job here given it has an IL that is much closer to source form... Would we want to record sth like a BLOCK for the scope of a loop in the loop structure? We'd also rely on the CLOBBERs inside to avoid leaking uses/defs. Of course a "simple" liveness analysis like that done during RTL expansion is possible as well. But I fear that it might not be good enough.
