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