Hi, > On Jun 7, 2021, at 2:53 AM, Richard Biener <rguent...@suse.de> wrote: > >> >> To address the above suggestion: >> >> My study shows: the call to __builtin_clear_padding is expanded during >> gimplification phase. >> And there is no __bultin_clear_padding expanding during rtx expanding phase. >> However, for -ftrivial-auto-var-init, padding initialization should be done >> both in gimplification phase and rtx expanding phase. >> since the __builtin_clear_padding might not be good for rtx expanding, >> reusing __builtin_clear_padding might not work. >> >> Let me know if you have any more comments on this. > > Yes, I didn't suggest to literally emit calls to __builtin_clear_padding > but instead to leverage the lowering code, more specifically share the > code that figures _what_ is to be initialized (where the padding is) > and eventually the actual code generation pieces. That might need some > refactoring but the code where padding resides should be present only > a single time (since it's quite complex).
Okay, I see your point here. > > Which is also why I suggested to split out the padding initialization > bits to a separate patch (and option). Personally, I am okay with splitting padding initialization from this current patch, Kees, what’s your opinion on this? i.e, the current -ftrivial-auto-var-init will NOT initialize padding, we will add another option to Explicitly initialize padding. Qing > > Richard.
