Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

["Martin Liška" <mliska@suse.cz>]

On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> My memory is weak, but isn't this something the sanopt pass
> (sanopt_optimize) is already doing similarly for e.g. ASAN_CHECK, UBSAN_NULL
> and UBSAN_VPTR checks?  For ASAN_MARK, you actually don't care about any
> calls, those shouldn't unpoison or poison again the vars under compiler's
> back.

Hi Jakub.

Your memory is not weak, it's exactly what to pass does. I've spent quite some
time reading and understanding the optimization (and finding PR78106) and looks
very similar to what we have for ASAN_MARK. However it's more complicated due
to existence of poisoning and unpoisoning calls.

In the previous email, you summarized what "patterns" can be optimized out:

1) - optimization to remove ASAN_MARK unpoisoning at the start of the function
2) - optimization to remove ASAN_MARK poisoning at the end of function (and
  remove epilogue unpoisoning)
3) - optimization to remove ASAN_MARK unpoisoning followed by ASAN_MARK poisoning
  or vice versa if there are no memory accesses in between

I'll come with more generalization:

Ia) ASAN_MARK poisonining followed by ASAN_MARK unpoisoning with no memory access
    in between => ASAN_MARK poisoning can be removed; 
Ib) ASAN_MARK unpoisonining followed by ASAN_MARK poisoning with no memory access
    in between => ASAN_MARK unpoisoning can be removed; 

Ia + Ib match exactly with 3). As function epilogue contains unpoisoning, Ia) == 2)

IIa) ASAN_MARK poisoning followed by ASAN_MARK poisoning => second ASAN_MARK can be removed
IIb) ASAN_MARK unpoisoning followed by ASAN_MARK unpoisoning => second ASAN_MARK can be removed

IIb matches 1)

III) ASAN_CHECK(&var) followed by ASAN_CHECK(&var) with no ASAN_MARK poisoning in between =>
     second ASAN_CHECK can be removed (this is more aggressive than what current
     can do maybe_optimize_asan_check_ifn).

Notes:
- Compared to current imm_dom_path_with_freeing_call_p, we would need 3 such predicates:
  x) imm_dom_path_with_asan_check () - needed by Ia, Ib
  y) imm_dom_path_with_asan_mark_poisoning () - this should return set of variables which
     can be potentially poisoned - needed by IIb and III
  z) imm_dom_path_with_asan_mark_unpoisoning () - this should return set of variables
     which can be potentially unpoisoned - needed by IIa

I would appreciate a feedback about my brainstorming I did about sanopt porting to use-after-scope,
maybe my cases are more generic that we would eventually need. And I'm not 100% convinced that all my
patterns described above would be doable in a similar way as current sanopt algorithm is done?

Thanks,
Martin