On Wed, Nov 2, 2016 at 1:56 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote: >> > Unless I'm missing something we either need to perform further analysis >> > during the addressable subpass - this variable could be made >> > non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA >> > form there be any SSA uses of the poisoning ASAN_MARK? If yes, keep it >> > addressable, otherwise rewrite into SSA. >> > Or, just rewrite it into SSA always, but turn the poisoning ASAN_MARK into >> > some new internal ECF_CONST call var_5 = ASAN_POISON (); and if we have any >> > uses of those, rewrite it back into addressable immediately or later or >> > something. >> >> Or just give up optimizing (asan has a penalty anyway)? Or > > Well, asan has a penalty and -fsanitize-use-after-scope even bigger penalty, > but the point is to make that penalty bearable. > >> re-structure ASAN_POISON () >> similar to clobbers: >> >> var = ASAN_POISION (); >> >> that avoids the address-taking and thus should be less heavy-weight on >> optimizations. > > Yeah, that is what I meant. The issue is how to report uses of such > SSA_NAME when there is no memory. So, either we'd need a special runtime > library entrypoint that would report uses after scope even when there is no > underlying memory, or we'd need to force it at asan pass time into memory > again.
Well, there can't be any uses outside the scope -- there are no (memory) uses left if we rewrite the thing into SSA. That is, the address can no longer "escape". Of course there could have been invalid uses before the rewrite into SSA. But those can be diagnosed either immediately before or after re-writing into SSA at compile-time (may be in dead code regions of course). Richard. > Jakub
