Need Help: Initialize paddings for -ftrivial-auto-var-init

Richard Biener rguenther@suse.de
Mon Jul 19 10:33:39 GMT 2021


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 <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


More information about the Gcc-patches mailing list