On Fri, 16 Jul 2021, Qing Zhao wrote:
> Hi,
>
> After some more study on __builtin_clear_padding and the corresponding
> testing cases.
> And also considered both Richard Biener and Richard Sandiford’s previous
> suggestion to use
> __builtin_clear_padding. I have the following thought on the paddings
> initialization:
>
> ****** We can insert a call to __builtin_clear_padding (&decl, 0) to all the
> variables that need to be
> Auto-initialized during gimplification phase. This include two places:
>
> A. If the auto-variable does not have an explicit initializer, and we
> need to add a call to .DEFERRED_INIT.
> We always add a call to __builtin_clear_padding following this
> .DEFERRED_INIT call.
>
> structure_type temp;
>
> temp = .DEFERRED_INIT ();
> __builtin_clear_padding (&temp, 0);
>
>
> NOTE:
> ****** If temp has a type without paddings, then
> __builtin_clear_padding will be lowered to a gimple_nop automatically.
> ****** regardless with zero or pattern init, the paddings will be
> always initialized to ZEROes, which is compatible with CLANG.
>
>
> B. If the auto-variable does HAVE an explicit initializer, then we will
> add the call to __builtin_clear_padding
> In the beginning of “gimplify_init_constructor”.
>
>
> structure_type temp = {…..};
>
>
> __builtin_clear_padding (&temp, 0);
> Expand_the_constructor;
>
> NOTE:
> ****** if temp has a type without padding, the call to
> __builtin_clear_padding will be lowed to gimple_nop;
> ****** padding will be always initialized to ZEROes.
>
>
> ******the major benefit with this approach are:
>
> 1. Padding initialization will be compatible with CLANG;
Irrelevant IMHO.
> 2. Implemenation will be much more simple and consistent;
Really? We're block-initializing now, so how is it simpler to
initialize padding separately?
> My questions:
>
> 1. What do you think of this approach?
I wonder why we're going back to separate padding initialization?
> 2. During implementation, if I want to add the following routine:
>
> /* Generate padding initialization for automatic vairable DECL.
> C guarantees that brace-init with fewer initializers than members
> aggregate will initialize the rest of the aggregate as-if it were
> static initialization. In turn static initialization guarantees
> that padding is initialized to zero. So, we always initialize paddings
> to zeroes regardless INIT_TYPE.
> To do the padding initialization, we insert a call to
> __BUILTIN_CLEAR_PADDING (&decl, 0).
> */
> static void
> gimple_add_padding_init_for_auto_var (tree decl, gimple_seq *seq_p)
> {
> ?????? how to build a addr_of_decl tree node???
> tree addr_of_decl = ….
= build_fold_addr_expr (decl);
> gimple *call = gimple_build_call (builtin_decl_implicit
> (BUILT_IN_CLEAR_PADDING),
> 2, addr_of_decl, build_zero_cst
> (TREE_TYPE (decl));
> gimplify_seq_add_stmt (seq_p, call);
> }
>
>
> I need help on how to build “addr_of_decl” in the above routine.
>
> Thanks a lot for your help.
>
> Qing
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
