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