On Thu, Jun 11, 2020 at 1:52 PM Eric Botcazou <botca...@adacore.com> wrote: > > Hi, > > gimplify_modify_expr_rhs has an optimization whereby the assignment to an > aggregate variable from a read-only object with a DECL_INITIAL is optimized > into the direct assignment of the DECL_INITIAL, provided that no temporary is > created in the process. > > The optimization is blocked if the read-only object is volatile, which is OK > as per the semantics of volatile, but also if the target variable is volatile, > on the grounds that the modified assignment might end up being done on a per > field basis, which is also OK. But this latter restriction is enforced a > priori and there are cases where the modified assignment would be OK, for > example if there is only one field or the DECL_INITIAL is equivalent to the > empty CONSTRUCTOR, i.e. all zeros. > > So, in the latter case, the patch changes gimplify_modify_expr_rhs to ask > gimplify_init_constructor whether the assignment would be done as a block, > which is easy because gimplify_init_constructor knows that it must create a > temporary if the LHS is volatile and this would not be the case, so it's just > a matter of completing the NOTIFY_TEMP_CREATION mechanism for this case. > > Tested on x86-64/Linux, OK for the mainline?
OK. Richard. > > 2020-06-11 Eric Botcazou <ebotca...@adacore.com> > > * gimplify.c (gimplify_init_constructor) <AGGREGATE_TYPE>: Declare new > ENSURE_SINGLE_ACCESS constant and move variables down. If it is true > and all elements are zero, then always clear. Return GS_ERROR if a > temporary would be created for it and NOTIFY_TEMP_CREATION is set. > (gimplify_modify_expr_rhs) <VAR_DECL>: If the target is volatile but > the type is aggregate non-addressable, ask gimplify_init_constructor > whether it can generate a single access to the target. > > > 2020-06-11 Eric Botcazou <ebotca...@adacore.com> > > * gnat.dg/aggr30.adb[sb]: New test. > > -- > Eric Botcazou
