[patch] PR32901: handle assignment...(and PR34465 and PR34448)
Wed Dec 19 11:57:00 GMT 2007
On 12/14/07 16:25, Aldy Hernandez wrote:
> Also... in a subsequent patch we should really look into merging
> consecutive initializations of aggregate fields-- sometime before
> expand. Jakub has suggested TER. I volunteer to do the work once I'm
> done with this.
Any reason why you couldn't do this directly in the gimplifier? Instead
of emitting the separate field assignments, just emit a single
CONSTRUCTOR assignment. You already have the DECL_INITIAL constructor
after all. I haven't thought it through, so the suggestion may be nonsense.
> @@ -3119,11 +3119,18 @@ gimplify_init_ctor_eval (tree object, VE
> Note that we still need to clear any elements that don't have explicit
> initializers, so if not all elements are initialized we keep the
> - original MODIFY_EXPR, we just remove all of the constructor elements. */
> + original MODIFY_EXPR, we just remove all of the constructor elements.
> + If NOTIFY_TEMP_CREATION is true, do not gimplify, just return
> + GS_ERROR if we would have to create a temporary when gimplifying
> + this constructor. Otherwise, return GS_OK.
> + If NOTIFY_TEMP_CREATION is false, just do the gimplification. */
Hmm, I don't much like this part. This function is supposed to just
gimplify the constructor. The tests for NOTIFY_TEMP_CREATION are simple
enough to be hoisted into a single predicate for
gimplify_modify_expr_rhs to use.
Otherwise, this one function grows in complexity and it already is a bit
> + tree old_from = *from_p;
> + /* Move the constructor into the RHS. */
> + *from_p = unshare_expr (DECL_INITIAL (*from_p));
As Jakub suggested, this unsharing is better done after the check.
OK with that refactoring.
More information about the Gcc-patches