[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Richard Biener rguenther@suse.de
Mon Jun 7 07:50:54 GMT 2021


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
> 


More information about the Gcc-patches mailing list