[llvm-dev] RFC: Removing ptrtoint from asan instrumentation (original) (raw)

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sat Jul 11 11:49:38 PDT 2020

On 7/10/20 2:33 AM, Sharma, Reshabh Kumar via llvm-dev wrote:

...

Hi everyone, Asan instrumentationintroduces a ptrtointinstruction which is used as an argument to a number ofruntime functions. Every instrumented load/store ends up having at least one ptrtointattached to its address.However, the community has now raised anumber ofconcerns about the use of LLVM generated ptrtoint& inttoptr[1]and have pointed out its effecton different optimizations. ptrtoint/inttoptrleads to conservative analysis results which does affect the performance. We are thinking of extending the LLVM sanitizers, starting with asan, to heterogeneoussituations such as those found in OpenCLandHIP.This will require asanto handle address spacesother than default 0.We want to handle address spacessimilarly to howit is done in the present asaninstrumentation, 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 ptrtointintroduced by the instrumentation hinderoptimizations that are important for OpenCL and other heterogeneous languages which directly or indirectly use address spaces.For example, InferAddressSpacewhichstaticallydeterminesthe address space of generic addresses, it does not work after seeing ptrtointas 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 introducedptrtointin instrumentation is the fact that all runtime function expectsthe address as a uptr(uptris unsigned long).Changing the data type of addresses passed to sanitizerruntime functionsfrom uptrto void* will eliminate the need forthe conversionto integer using ptrtoint. Removing the ptrtointfrom asaninstrumentation will boost the performance andwill reduce the differenceswith uninstrumentedcode. 1. http://lists.llvm.org/pipermail/llvm-dev/2019-January/129095.html <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129095.html> Many thanks, Reshabh and Brian

First, let me say that I think it's wonderful that you're interested in making the sanitizers work in heterogeneous environments. I definitely hope that you're able to make this work.

Second, for the reasons you've highlighted, our best practice is for optimizations not to introduce ptrtoint/inttoptr. i8* GEPs, along with casts as necessary, are preferred whenever possible. Given that one benefit of the Sanitizers is that the instrumentation can be optimized along with the program, I think it makes sense to consider these instrumentation passes in that category. It's true that, in the traditional use case, the fact that the ptrtoint obscures aliasing information isn't a big deal when the int is just being passed into a function with side effects (as it sounds like is the case here). If we have a use case that motivates changing this, however, I think that we should consider doing so.

 -Hal

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200711/2cc28efc/attachment-0001.html>

More information about the llvm-dev mailing list