> On Jul 19, 2021, at 5:33 AM, Richard Biener <rguent...@suse.de> wrote:
>
> 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.
Even though it’s not very important, I think that it will be nicer if we can
make it.
>
>> 2. Implemenation will be much more simple and consistent;
>
> Really? We're block-initializing now, so how is it simpler to
> initialize padding separately?
For pattern initialization, after the block-initializing, we can add the call
to __builtin_clear_padding to initialize the paddings with zeroes.
Then all the paddings will be initialized with zeroes regardless whether it’s
zero init or pattern init.
For zero initialization, after the block-initializing, we will Not add the call
to __builtin_clear_padding.
>
>> My questions:
>>
>> 1. What do you think of this approach?
>
> I wonder why we're going back to separate padding initialization?
This mainly due to the implementation for initialize paddings of
fully-initialized structure variables, we can add an additional
block-initializing for
paddings initialization before the real constructor initialization. Or we can
add a call to __builtin_clear_padding after the real constructor initialization
to only initialize the separate paddings.
Both approach should work, but after some study, I think adding call to
__builtin_clear_padding should be better due to:
1. Easier to be implemented. For the other approach, we will need to come up
with a new routine “type_has_padding” to decide whether we need to
add the block initialization for the structure, as both you and Richard
Sandiford commented before, this new routine “type_has_padding” SHOULE reuse
the current routine “clear_padding_type” in simple-fold.c, after my study, it’s
quite difficult to reorg “clear_padding_type” to be shared between
“gimple_fold_builtin_clear_padding”
and the new routine “type_has_padding”. And also after this detailed study, I
found that directly call “__builtin_clear_padding” might be more simpler
and clean.
2. Padding will be all zeroed regardless wether it’s zero init or pattern init.
I think that this is nicer than pattern initializing the paddings.
>> 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);
Thank you.
Qing
>
>> 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)
