> On Oct 18, 2021, at 12:15 PM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Oct 18, 2021 at 05:01:55PM +0000, Qing Zhao wrote: >>> The where is typically somewhere in the FEs. >>> But, there are two things. >>> One is that in order to gimplify it properly, it needs to be marked earlier. >>> But the other is that if it is not addressable, then clearing padding in it >>> makes not much sense as I've tried to explain, all it could do is making it >>> slightly less likely that the var will be optimized into a gimple reg later, >>> but if it does, then the padding will not be cleared anyway. >>> And it is only at RTL expansion or RA that the var could be assigned into a >>> stack location or spilled and at that point is the right time to clear >>> padding in there if needed. >>> So while the FEs could make it addressable and then you could clear padding, >>> it would just penalize code and nothing else, later on the optimizations >>> would figure out it is no longer addressable and optimize it into gimple >>> reg. >> >> So, from my understanding so far, adding “!is_gimple_reg(decl)” to decide >> whether to add __builtin_clear_padding call >> is a good and simple solution to this bug? > > Yes. > And if you want to do something during RTL expansion or RA time, > do it there incrementally after reasoning why it is needed at those points.
I already created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102781 For this RTL phase padding clearing. (Mostly for long double/_Complex long double variables that have explicit initializer, I guess). It’s hard to come up with a simple testing case yet for this PR. > E.g. for the spill slots, it doesn't have to be any kind of user variable > but can be any kind of intermediate temporary... However, for -ftrivial-auto-var-init, we suppose to clear the user variables, shall we clear intermediate temporary variables with this option? Qing > > Jakub >
