> 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)