Re: [PATCH] Optimize UBSAN_NULL checks, add sanopt.c

[Marek Polacek <polacek@redhat.com>]

On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
> On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
> > On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
> > > Are you going to work on ASan soon?  I could rebase my patches on top of
> > > Marek's infrastructure.
> > 
> > I'm not going to work on ASan today or tomorrow, but it'd be nice to
> > get this ASan opt in in this stage1.
> > 
> > So if you can rebase your patch, I think that will be appreciated.
> 
> Note, the algorithm we were discussing with Honza for the
> "is there any possibility of a freeing call on the path between a dominating
> and dominated ASAN_CHECK"

Right.  Let me see then if I can implement the following soon, maybe
it makes sense to rebase Yuri's patch only on top of this algorithm.

> problem was to compute it lazily; have flags for asan per-bb:
> 1) bb might contain a !nonfreeing_call_p
> 2) there is a bb with flag 1) set in some path between imm(bb) and bb
> 3) flag whether 2) has been computed already
> 4) some temporary "being visited" flag
> and the algorithm:
> 1) when walking a bb, if you encounter a !nonfreeing_call_p call, either
>    immediately nuke recorded earlier ASAN_CHECKs from the current bb,
>    or use gimple_uids for lazily doing that; but in any case, record
>    the flag 1) for the current bb
> 2) if you are considering ASAN_CHECK in a different bb than ASAN_CHECK
>    it is dominating, check the 2) flag on the current bb, then on
>    get_immediate_dominator (bb) etc. until you reach the bb with the
>    dominating bb, if the 2) flag is set on any of them, don't optimize;
>    if the 2) flag is not computed on any of these (i.e. flag 3) unset),
>    then compute it recursively; set the 4) flag on a bb, for incoming
>    edges if the src bb is not the imm(bb) of the original bb, and does
>    not have 4) flag set: if it has 1) set, use 1, if it has 3) flag set,
>    use 2), otherwise recurse (and or the result); unset 4) flag before
>    returning; or so.
> 
> For tsan, pretty much the same thing, just with different 1)/2)/3)
> flags and different test for that (instead of !nonfreeing_call_p
> we are interested in: uses atomics or calls that might use atomics
> or other pthread_* synchronization primitives).

	Marek