Re: [PATCH RFA] gimplify: avoid unnecessary copy of init array [PR105838]

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/8/22 15:01, Jason Merrill via Gcc-patches wrote:
> After the previous patches, I noticed that we were putting the array of
> strings into .rodata, but then memcpying it into an automatic array, which
> is pointless; we should be able to use it directly.
> 
> C++ doesn't allow us to do this for the backing array of an
> initializer_list, but should be able to do it for the implementation detail
> array we use to construct the backing array.
> 
> This doesn't happen automatically because TREE_ADDRESSABLE is set, and
> gimplify_init_constructor uses that to decide whether to promote a variable
> to static.  Ideally this could use escape analysis to recognize that the
> address, though taken, never leaves the function; that should allow
> promotion when we're only using the address for indexing within the
> function, as in initlist-opt2.C.
> 
> But in initlist-opt1.C, we're passing the array address to another function,
> so it definitely escapes; it's only safe in this case because it's calling a
> standard library function that we know only uses it for indexing.  So, a
> flag seems needed.  I first thought to put the flag on the TARGET_EXPR, but
> the VAR_DECL seems more appropriate.
> 
> Bikeshedding, or other approaches, welcome.
> 
> 	PR c++/105838
> 
> gcc/ChangeLog:
> 
> 	* tree.h (DECL_NOT_OBSERVABLE): New.
> 	* tree-core.h (struct tree_decl_common): Mention it.
> 	* gimplify.cc (gimplify_init_constructor): Check it.
> 
> gcc/cp/ChangeLog:
> 
> 	* call.cc (maybe_init_list_as_array): Set DECL_NOT_OBSERVABLE.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/tree-ssa/initlist-opt1.C: Check for static array.
> 	* g++.dg/tree-ssa/initlist-opt2.C: Likewise.
Presumably the DECL in question isn't actually compiler generated and 
thus DECL_ARTIFICIAL is not appropriate here.  Assuming that's the case, 
should we be setting DECL_NON_OBSERVABLE on VAR_DECLs with 
DECL_ARTIFICIAL set?  I don't think that needs to be done for this patch 
to move forward though.

There haven't been any objections, so OK.


Jeff