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 >