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. 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... Jakub