This is an archive of the discontinued LLVM Phabricator instance.

[asan] Speed up interesting alloca checks
ClosedPublic

Authored by zaks.anna on Mar 26 2015, 10:16 AM.

Details

Reviewers
kcc
Summary

We make many redundant calls to isInterestingAlloca in the AddressSanitzier pass. This is especially inefficient for allocas that have many uses. Let's cache the results to speed up compilation.

The compile time improvements depend on the input. I did not see much difference on benchmarks; however, I have a test case where compile time goes from minutes to under a second.

Diff Detail

Event Timeline

zaks.anna updated this revision to Diff 22731.Mar 26 2015, 10:16 AM
zaks.anna retitled this revision from to [asan] Speed up interesting alloca checks.
zaks.anna updated this object.
zaks.anna edited the test plan for this revision. (Show Details)
zaks.anna added subscribers: Unknown Object (MLST), kubamracek, kcc and 2 others.
kcc added a comment.Mar 26 2015, 11:31 AM

This looks fine, but I would slightly prefer to compute the map beforehand instead of caching, if possible.
I.e. instead of a map of ProcessedAllocas have a set of InterestingAllocas that is computed in visitAllocaInst

lib/Transforms/Instrumentation/AddressSanitizer.cpp
811

we tend to not write {} in such cases

This looks fine, but I would slightly prefer to compute the map beforehand instead of caching, if possible.
I.e. instead of a map of ProcessedAllocas have a set of InterestingAllocas that is computed in visitAllocaInst

In the future, determining if an alloca is interesting or not might depend on visiting all of its uses. For example, if an alloca is promotable but all of it's uses are accessing memory, which is provably in range, it should be marked as non-interesting. The current approach seems to fit that model better than visiting allocas and building a list.

kcc added a comment.Mar 26 2015, 2:17 PM

This looks fine, but I would slightly prefer to compute the map beforehand instead of caching, if possible.
I.e. instead of a map of ProcessedAllocas have a set of InterestingAllocas that is computed in visitAllocaInst

In the future, determining if an alloca is interesting or not might depend on visiting all of its uses. For example, if an alloca is promotable but all of it's uses are accessing memory, which is provably in range, it should be marked as non-interesting. The current approach seems to fit that model better than visiting allocas and building a list.

But you can also visit all uses in a pre-compute step too.
And having this pre-computed instead of cached will make the code simpler to understand.

kcc added a comment.Mar 26 2015, 3:34 PM

Each walk of the use list of the alloca is relatively expensive -- it is a linked list and cache hostile.

But won't we need it anyway regardless of caching-cs-precomputing?

kcc accepted this revision.Mar 26 2015, 6:51 PM
kcc added a reviewer: kcc.

LGTM (with a nit about {})

We currently do not run an instruction visitor in the very beginning of the pass

Yes, indeed.

This revision is now accepted and ready to land.Mar 26 2015, 6:51 PM

Thanks for the feedback everyone! Committed in r233397.

zaks.anna closed this revision.Jun 25 2015, 6:14 PM