Re: [Patch][PR102281]do not add BUILTIN_CLEAR_PADDING for variables that are gimple registers.

[Qing Zhao <qing.zhao@oracle.com>]

> On Oct 18, 2021, at 11:46 AM, Jakub Jelinek <jakub@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
>