https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Martin Liška from comment #9) > Thanks Jakub for your thoughts. I was also thinking about simple approach > similar to what we do for use-after-scope in situations where there's a > usage of IFN_ASAN_POISON. In that case we generate a 'shadow' variable > that's poison/unpoisoned, etc. We can come up with automatic variables to > which we assign an addressable PARM_DECL and then these variables will be > normally protected with red zones. I can imaging bigger performance gap, but > it can be quite easily doable I guess? That would work too. If doing it this way, it would be desirable to do it late in the GIMPLE pass queue, e.g. in the sanopt pass, for the TREE_ADDRESSABLE PARM_DECLs that don't have TREE_ADDRESSABLE types (those are passed by invisible reference) create the DECL_ARTIFICIAL VAR_DECLs, have them TREE_ADDRESSABLE, add code to copy the PARM_DECLs to those vars at the beginning of the function, clear TREE_ADDRESSABLE on the PARM_DECLs and remap all uses of the PARM_DECLs except the newly added ones to the new VAR_DECLs. Not sure if the PARM_DECLs should have DECL_VALUE_EXPR pointing to the VAR_DECLs (e.g. for debug info purposes), and whether the artificial VAR_DECLs should be added to some BLOCK_VARS or not.
