On Thu, 3 Jun 2021, Qing Zhao wrote:
> Hi, Richard,
>
> For the following, I need more clarification:
>
>
>
> +/* Expand the IFN_DEFERRED_INIT function according to its second
> argument. */
> +static void
> +expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> +{
> + tree var = gimple_call_lhs (stmt);
> + tree init = NULL_TREE;
> + enum auto_init_type init_type
> + = (enum auto_init_type) TREE_INT_CST_LOW (gimple_call_arg (stmt, 1));
> +
> + switch (init_type)
> + {
> + default:
> + gcc_unreachable ();
> + case AUTO_INIT_PATTERN:
> + init = build_pattern_cst_for_auto_init (TREE_TYPE (var));
> + expand_assignment (var, init, false);
> + break;
> + case AUTO_INIT_ZERO:
> + init = build_zero_cst (TREE_TYPE (var));
> + expand_assignment (var, init, false);
> + break;
> + }
>
> I think actually building build_pattern_cst_for_auto_init can generate
> massive garbage and for big auto vars code size is also a concern and
> ideally on x86 you'd produce rep movq. So I don't think going
> via expand_assignment is good. Instead you possibly want to lower
> .DEFERRED_INIT to MEMs following expand_builtin_memset and
> eventually enhance that to allow storing pieces larger than a byte.
>
>
> I will lower .DEFFERED_INIT to MEMS following expand_builtin_memset for
> “AUTO_INIT_PATTERN”.
> My question is:
> Do I need to do the same for “AUTO_INIT_ZERO”?
No, the representation for a general "zero constant" for aggregates is
just a single CONSTRUCTOR node with zero explicit elements and thus
quite optimal.
Richard.
> Thanks.
>
> Qing
>
