[llvm-dev] RFC: Removing ptrtoint from asan instrumentation

[Sharma, Reshabh Kumar via llvm-dev]

[AMD Official Use Only - Internal Distribution Only]


Hi everyone,


Asan instrumentation introduces a ptrtoint instruction which is used as an argument to a number of runtime functions. Every instrumented load/store ends up having at least one ptrtoint attached to its address. However, the community has now raised a number of concerns about the use of LLVM generated ptrtoint & inttoptr [1] and have pointed out its effect on different optimizations.  ptrtoint/inttoptr leads to conservative analysis results which does affect the performance.



We are thinking of extending the LLVM sanitizers, starting with asan, to heterogeneous situations such as those found in OpenCL and HIP. This will require asan to handle address spaces other than default 0. We want to handle address spaces similarly to how it is done in the present asan instrumentation, using inline shadow memory mapping. The required information to calculate shadow address is not known for a few address spaces at compile time, and for such use cases we plan to introduce runtime calls that can return the required shadow address.



The ptrtoint introduced by the instrumentation hinder optimizations that are important for OpenCL and other heterogeneous languages which directly or indirectly use address spaces. For example,  InferAddressSpace which statically determines the address space of generic addresses, it does not work after seeing ptrtoint as one of the uses. The same applies to any optimization that deals with alias analysis or pointers in general.



The hurdle in getting rid of the introduced ptrtoint in instrumentation is the fact that all runtime function expects the address as a uptr (uptr is unsigned long). Changing the data type of addresses passed to sanitizer runtime functions from uptr to void* will eliminate the need for the conversion to integer using ptrtoint. Removing the ptrtoint from asan instrumentation will boost the performance and will reduce the differences with uninstrumented code.



  1.  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129095.html

Many thanks,
Reshabh and Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200710/8d50223c/attachment.html>