On Tue, 18 Nov 2014, Richard Biener wrote:
> On Tue, 18 Nov 2014, Eric Botcazou wrote:
>
> > > Now - I can see how that is easily confused by the static chain
> > > being address-taken. But I also remember that Eric did some
> > > preparatory work to fix that, for nested functions, that is,
> > > possibly setting DECL_NONADDRESSABLE_P? Don't remember exactly.
> >
> > The preparatory work is DECL_NONLOCAL_FRAME. The complete patch which does
> > something along these lines is attached to PR tree-optimization/54779
> > (latest
> > version, for a 4.9-based compiler).
>
> Ah, now I remember - this was to be able to optimize away the frame
> variable in case the nested function was inlined.
>
> Toms case is somewhat different as I undestand as somehow LIM store
> motion doesn't handle indirect frame accesses well enough(?) So
> he intends to load register vars in the frame into registers at the
> beginning of the nested function and restore them to the frame on
> function exit (this will probably break for recursive calls, but
> OMP offloading might be special enough that this is a non-issue there).
>
> So marking the frame decl won't help him here (I thought we might
> mark the FIELD_DECLs corresponding to individual vars). OTOH inside
> the nested function accesses to the static chain should be easy to
> identify.
Tom - does the following patch help?
Thanks,
Richard.
Index: gcc/omp-low.c
===================================================================
--- gcc/omp-low.c (revision 217692)
+++ gcc/omp-low.c (working copy)
@@ -1517,7 +1517,8 @@ fixup_child_record_type (omp_context *ct
layout_type (type);
}
- TREE_TYPE (ctx->receiver_decl) = build_pointer_type (type);
+ TREE_TYPE (ctx->receiver_decl)
+ = build_qualified_type (build_reference_type (type), TYPE_QUAL_RESTRICT);
}
/* Instantiate decls as necessary in CTX to satisfy the data sharing