On Thu, 3 Jun 2021, Qing Zhao wrote: > Hi, Richard, > > > On May 26, 2021, at 6:18 AM, Richard Biener > <rguent...@suse.de<mailto:rguent...@suse.de>> wrote: > > On Wed, 12 May 2021, Qing Zhao wrote: > > Hi, > > This is the 3rd version of the patch for the new security feature for GCC. > > Please take look and let me know your comments and suggestions. > > > +/* Returns true when the given TYPE has padding inside it. > + return false otherwise. */ > +bool > +type_has_padding (tree type) > +{ > + switch (TREE_CODE (type)) > + { > + case RECORD_TYPE: > + { > > btw, there's __builtin_clear_padding and a whole machinery around > it in gimple-fold.c, I'm sure that parts could be re-used if they > are neccessary in the end. > > 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). Which is also why I suggested to split out the padding initialization bits to a separate patch (and option). Richard.
