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

[Hal Finkel via llvm-dev]

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>