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
