> On Oct 18, 2021, at 11:46 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Oct 18, 2021 at 03:58:56PM +0000, Qing Zhao wrote: >>> Furthermore, __builtin_clear_padding doesn't assume anything, but it takes >>> an address of an object as argument and already the taking of the address >>> that gimple_add_padding_init_for_auto_var does makes the var >>> TREE_ADDRESABLE, which is something that needs to be done before the var is >>> ever accessed during gimplification. >> >> Yes, currently, “gimple_add_padding_init_for_auto_var” has already done the >> following before >> calling __builtin_clear_padding: >> >> mark_addressable (decl); >> addr_of_decl = build_fold_addr_expr (decl); >> >> But looks like that “making the DECL as ADDRESSABLE here” is too late. > > Wouldn't be if we could prove it wasn't gimplified already. > >> Yes, If we can “make the DECL as ADDRESSABLE” before the var is accessed >> during gimplification, that will also >> fix this issue. But “Where” is the right place to make the DECL as >> ADDRESSABLE? (Do it in “gimplify_decl_expr” when handling >> The variable’s declaration? ) > > 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? Qing > > Jakub >
