[PATCH] Optimize UBSAN_NULL checks, add sanopt.c

Jakub Jelinek jakub@redhat.com
Wed Nov 5 10:50:00 GMT 2014


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"
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).

	Jakub



More information about the Gcc-patches mailing list