# Memory Access Instrumentation

This is a study of how memory access instrumentation affects a program's performance. [Memory access instrumentation](https://github.com/llvm/llvm-project/blob/985d64b03accbed8500a85372d716367d89b61be/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp#L637-L653) refers to a function call to a corresponding handler for a memory access event. See the following example in which instrumentation is added to a simple memory access (`y = x`) (annotated with `// *`).

tsan_read(x)
tsan_write(y)
y = x;

We aim to compare the 4 following builds in this study.

Builds:
1. NT: Normal program without any tsan
2. T-MInst: TSan without memory access instrumentation
3. T/MInst: TSan with memory access instrumentation but which does nothing
4. T: Full TSan

For (2), compile the program with [additional flags](https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags) `-mllvm -tsan-instrument-memory-accesses=false -mllvm -tsan-instrument-atomics=false`.

For (3), refer to [this commit](https://github.com/focs-lab/llvm-project/commit/28ccced9915b8ad8fb8d1948ae1be9d1b9458ae3).

I will return to this some time later. The main observation is that there is significant [front-end bound inefficiency](https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2024-2/top-down-microarchitecture-analysis-method.html) due to the instrumentation on memory accesses. I have yet to find a good way to analyse and present this in a useful way.