Re: How does address sanitizer handle read-modify-write memory access?
Konstantin Serebryany a écrit:
> When we have a code like X++ (either RMW, or a regular increment) it
> is enough for asan to instrument it just once (either as a read or a
> write, doesn't matter).
> LLVM implementation does this optimization for regular increments,
> while GCC does not (yet).
>
> % cat inc.cc
> void foo(int *a) {
> (*a)++;
> }
> % clang -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
> callq __asan_report_load4
> % gcc -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
> call__asan_report_load4
> call__asan_report_store4
>
> Doing two __asan_report* calls here is not a correctness bug, but a
> performance problem.
> I think we saw ~3%-5% performance gain due to this optimization in
> LLVM, i.e. this is nice to have, but not critical.
Right. I plan to work on this kind of optimizations on asan soonish. I
guess I should file a bug to track this in the mean time.
--
Dodji
Re: How does address sanitizer handle read-modify-write memory access?
On Mon, Dec 17, 2012 at 11:12:43AM +0100, Dodji Seketeli wrote:
> Konstantin Serebryany a écrit:
>
> > When we have a code like X++ (either RMW, or a regular increment) it
> > is enough for asan to instrument it just once (either as a read or a
> > write, doesn't matter).
> > LLVM implementation does this optimization for regular increments,
> > while GCC does not (yet).
> >
> > % cat inc.cc
> > void foo(int *a) {
> > (*a)++;
> > }
> > % clang -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
> > callq __asan_report_load4
> > % gcc -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
> > call__asan_report_load4
> > call__asan_report_store4
> >
> > Doing two __asan_report* calls here is not a correctness bug, but a
> > performance problem.
> > I think we saw ~3%-5% performance gain due to this optimization in
> > LLVM, i.e. this is nice to have, but not critical.
>
> Right. I plan to work on this kind of optimizations on asan soonish. I
> guess I should file a bug to track this in the mean time.
Yeah, the plan was first to introduce a new builtin, that is around only
between the asan/asan0 passes and some sanopt pass in between vectorizer and
expansion, teach alias oracle that the new builtin (which would stand for
the shadow memory address computation, test + noreturn call if load/store is
bad; probably with arguments of address, size and whether read/write) - that
the address doesn't really escape, and that it doesn't clobber any memory
the current TU is interested in, but can't be moved across calls that might
call malloc/free and similar, and then finally the sanopt pass to use
ssa_propagate or similar to find out what memory accesses have been already
instrumented in dominating place and we don't need to test them again, what
checks could be merged together (load + store into store check, wider size
check with narrower one), etc., then finally folding the remaining builtins
into the shadow memory load + noreturn call (perhaps that could be done
during expansion instead).
Jakub
Fw: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system
-Forwarded message- From: ETANI NORIKO To: iant Date: Sun, 16 Dec 2012 21:26:34 +0900 (JST) Subject: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system Dear Sir, Thank you for replying my e-mail. This is an implementation issue for OpenCL or parallel computing environment for embedded many-core system with Linux. OpneCL has two computing components which are a host core and a computing core. The reason why GCC is not available for a computing device of OpenCl is that a load address for a binary file must be specified by a developer. In a case of GCC, a load address for a binary file is specified by Linux system. Of course, we can use GCC on a host core, and we can use MPFR and GMP. However, as long as we use LD to link object files and create a binary file for a computing device core, we cannot use MPFR and GMP. Here, we would like to ask you as follows: 1) Can LD have a function to link MPFR and GMP like GCC? Or 2) MPFR and GMP are installed in GCC with GCC toolchain. Can MPFR and GMP be created as static libraries independent of GCC？ Best Regards, Noriko Etani -Original message- From:Ian Lance Taylor To:norik...@fc.ritsumei.ac.jp Cc:gcc Date:Tue, 11 Dec 2012 17:45:37 -0800 Subject:Re: MCSoC2013: to enhance embedded Linux for many-core system On Mon, Dec 10, 2012 at 2:00 AM, ETANI NORIKO wrote: > > We have been developing many-core system in a program of摘xtremely Low-power > Circuits and Systems (Green IT Project)敗ponsored by New Energy and Industrial > Technology Development Organization (NEDO) which is one of National Project > in Japan. > > We of Ritsumeikan University team are engaged in developing high-level API > for a parallel computing on device cores and the software developing > environment for many-core system. > > Here, we found out two important issues for the future of embedded Linux as > follows: > 1. uClibc cannot support some functions which glibc can support. > A embedded system is developed for a specific field, and requires some > functions in glibc. > 2. Math functions and full computing of float and double are supported with > MPFR and GMP libraries installed into GCC. > In many-core system, GCC is not available because a load address must be > specified. LD links object files and creates a binary file. This LD cannot > load MPFR and GMP libraries. So, a computing device in many-core system > cannot use math functions and full computing of float and double. You seem to be talking about issues that make it harder to run GCC, or indeed any conventional program, on your many-core system. Is that really what is interesting here? Why not run GCC on a conventional system as a cross-compiler, generating code for your many-core system? Ian
Fw: Re: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system
-Forwarded message- From: ETANI NORIKO To: iant Date: Sun, 16 Dec 2012 21:34:48 +0900 (JST) Subject: Re: [RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system Dear Sir, I would like to add my explanation to my former e-mail. >>The reason why GCC is not available for a computing device of OpenCl is that >>a load address for a binary file must be specified by a developer. In a case >>of GCC, a load address for a binary file is specified by Linux system. On a computing device core, an application is run on a kind of a driver for a computing device. As Linux OS is not installed on a computing device core, LD is inevitable. Regards, Noriko Etani -Original message- From:ETANI NORIKO To:iant Date:Sun, 16 Dec 2012 21:26:34 +0900 (JST) Subject:[RE-SENDING]Re: MCSoC2013: to enhance embedded Linux for many-core system Dear Sir, Thank you for replying my e-mail. This is an implementation issue for OpenCL or parallel computing environment for embedded many-core system with Linux. OpneCL has two computing components which are a host core and a computing core. The reason why GCC is not available for a computing device of OpenCl is that a load address for a binary file must be specified by a developer. In a case of GCC, a load address for a binary file is specified by Linux system. Of course, we can use GCC on a host core, and we can use MPFR and GMP. However, as long as we use LD to link object files and create a binary file for a computing device core, we cannot use MPFR and GMP. Here, we would like to ask you as follows: 1) Can LD have a function to link MPFR and GMP like GCC? Or 2) MPFR and GMP are installed in GCC with GCC toolchain. Can MPFR and GMP be created as static libraries independent of GCC？ Best Regards, Noriko Etani -Original message- From:Ian Lance Taylor To:norik...@fc.ritsumei.ac.jp Cc:gcc Date:Tue, 11 Dec 2012 17:45:37 -0800 Subject:Re: MCSoC2013: to enhance embedded Linux for many-core system On Mon, Dec 10, 2012 at 2:00 AM, ETANI NORIKO wrote: > > We have been developing many-core system in a program of摘xtremely Low-power > Circuits and Systems (Green IT Project)敗ponsored by New Energy and Industrial > Technology Development Organization (NEDO) which is one of National Project > in Japan. > > We of Ritsumeikan University team are engaged in developing high-level API > for a parallel computing on device cores and the software developing > environment for many-core system. > > Here, we found out two important issues for the future of embedded Linux as > follows: > 1. uClibc cannot support some functions which glibc can support. > A embedded system is developed for a specific field, and requires some > functions in glibc. > 2. Math functions and full computing of float and double are supported with > MPFR and GMP libraries installed into GCC. > In many-core system, GCC is not available because a load address must be > specified. LD links object files and creates a binary file. This LD cannot > load MPFR and GMP libraries. So, a computing device in many-core system > cannot use math functions and full computing of float and double. You seem to be talking about issues that make it harder to run GCC, or indeed any conventional program, on your many-core system. Is that really what is interesting here? Why not run GCC on a conventional system as a cross-compiler, generating code for your many-core system? Ian
