This is an archive of the discontinued LLVM Phabricator instance.

[esan] Add working set base runtime library
ClosedPublic

Authored by bruening on May 20 2016, 1:19 PM.

Details

Summary

Adds the base runtime library for the working set tool.
Adds slowpath code for updating the shadow memory.

To be added in the future:
+ Scan memory and report the total size.
+ Take samples for intermediate values.

Diff Detail

Repository
rL LLVM

Event Timeline

bruening updated this revision to Diff 57979.May 20 2016, 1:19 PM
bruening retitled this revision from to [esan] Add working set base runtime library.
bruening updated this object.
bruening added a reviewer: aizatsky.
bruening added subscribers: llvm-commits, eugenis, kcc and 2 others.
aizatsky added inline comments.May 20 2016, 1:32 PM
lib/esan/working_set.cpp
34 ↗(On Diff #57979)

Instead of bit fiddling, do you think a struct with bit fields would look better?

bruening added inline comments.May 20 2016, 3:09 PM
lib/esan/working_set.cpp
34 ↗(On Diff #57979)

Hmm, the issue is that all of the code (not just this CL, but code that uses the other 6 bits) operates on the bits in a way that is not very amenable to using separate named fields: samples at each bit level accumulate into the bit to the left, we would still be creating masks for word-level and other operations (rather than hoping the compiler turns several field references into a single mask), etc. While a struct might help with this top-level documentation, I don't think it would easily help with the actual code, and the declared field names would not be referenced.

I know you haven't seen any other code operating on the shadow values yet, so how about this: let's hold that thought, and once you see some future code that operates on all the bits, if you have an idea for how to use named bitfields in the code we can revisit at that point?

aizatsky added inline comments.May 20 2016, 3:26 PM
lib/esan/esan.cpp
120 ↗(On Diff #57979)

please introduce constants for these 2 & 6.

lib/esan/working_set.cpp
34 ↗(On Diff #57979)

SG let's see it coming.

If bitfields wouldn't work, it might be beneficial to extract lower-level shadow memory interface that contains all bit-fiddling. Not sure how similar would it be to processRangeAccessWorkingSet, but in the future I'd like to see these low-level details more contained and better structured.

53 ↗(On Diff #57979)

I don't really see a reason to do an if() check here. Why not blindly "*Shadow |= ShadowAccessedVal"? Is it really faster? I would guess that having a branch is not very good for performance?

bruening added inline comments.May 23 2016, 8:52 AM
lib/esan/working_set.cpp
53 ↗(On Diff #57979)

The check is faster. In every shadow tool we have ever made it is faster to load, compare, and only store if the value is not already there, than to perform a blind store.

bruening marked an inline comment as done.May 23 2016, 1:11 PM
bruening updated this revision to Diff 58142.May 23 2016, 1:14 PM

Add named constants for the shadow scale.

aizatsky accepted this revision.May 23 2016, 1:21 PM
aizatsky edited edge metadata.
This revision is now accepted and ready to land.May 23 2016, 1:21 PM
This revision was automatically updated to reflect the committed changes.
filcab added a subscriber: filcab.May 25 2016, 6:37 AM

Doing some minor post-commit review. Please don't add svn properties unless they're really needed.

Thank you,

Filipe

compiler-rt/trunk/lib/esan/esan.cpp
169

We should just validate Tool at the start of initializeLibrary, and set WhichTool after we validated it. That way we know that WhichTool is either uninitialized or a valid tool. We should also remove the assignment to WhichTool from __esan_init and only do it here, in initializeLibrary (currently we're setting it twice (at least)).

compiler-rt/trunk/lib/esan/esan_interface_internal.h
32

I'd rather have something like ESAN_MaxTool or something. A more descriptive name than simply Max.

compiler-rt/trunk/lib/esan/working_set.cpp
52

Please, no magic constants. alignof(u32) would be better.

63

sizeof(u32)

64

I'd rather just have a u32 *ShadowWord = Shadow before this block, and just use that pointer.
It minimizes "line noise" and is more explicit on what we're doing.

69

And remember to update Shadow from ShadowWord, of course.

80

Do we want this to be a flag, then?
This seems weird. This should probably be set somewhere close to the mapping, since they're so tied to each other.
And we can just add a VReport to the initialization function to print it for a verbosity level higher than 1.

filcab added inline comments.May 25 2016, 6:41 AM
lib/esan/working_set.cpp
53 ↗(On Diff #57979)

I'd guess we end up having lots of shared cache locations. If we were writing all the time, then we'd end up with lots of cache/memory traffic for no reason, and the lines would be marked as exclusive all the time.
(Unless there are some cache optimizations where it doesn't change the state (any more than a read would) if the bit pattern written to it is the same. I'm not sure these exist)

Please don't add svn properties unless they're really needed.

It was not clear what you were referring to. Looking at it it seems that there are some svn:eol-style properties being auto-added by git-svn. Turning off core.autocrlf should avoid this in the future. Looking around I see a number of existing files with this property (e.g., 7 files in lib/asan/) so this seems like a common problem and should probably be mentioned at http://llvm.org/docs/GettingStarted.html.