This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, 8/8] Do simple omp lowering for no address taken var
- From: Richard Biener <rguenther at suse dot de>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Tom de Vries <Tom_deVries at mentor dot com>, Jakub Jelinek <jakub at redhat dot com>, Thomas Schwinge <Thomas_Schwinge at mentor dot com>
- Date: Tue, 18 Nov 2014 10:36:44 +0100 (CET)
- Subject: Re: [PATCH, 8/8] Do simple omp lowering for no address taken var
- Authentication-results: sourceware.org; auth=none
- References: <546743BC dot 5070804 at mentor dot com> <54678C29 dot 40006 at mentor dot com> <alpine dot LSU dot 2 dot 11 dot 1411171104160 dot 374 at zhemvz dot fhfr dot qr> <1806387 dot g87bzpZJr0 at polaris>
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.
Richard.