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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4