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
