On 11/05/2014 04:23 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 04:13:01PM +0300, Yury Gribov wrote:
Wouldn't it break most uses of __asan_poison_memory_region ?
Most probably but I wonder if we should ask people to simply do asm
volatile with memory clobber in this case? And we probably shouldn't
call the whole thing is_nonfreeing anyway.
Added Kostya to maybe comment on this.
Well, right now !nonfreeing_call_p is any non-builtin call or
non-leaf builtin call (i.e. builtin that might call functions in the
current CU), or free/tm_free/realloc/stack_restore.
So, by this definition __asan_poison_memory_region is also a
!nonfreeing_call_p. Where would you like to see the volatile with
memory clobber?
>
You might very well just call some function that
does the free for you.
*p = 1;
foo (p);
*p = 2;
and foo (p) could asm volatile ("" : : : "memory"); somewhere
and free (p) somewhere else.
I was thinking about e.g. removing check for the second access in
extern int x[];
void foo (int i) {
x[i] = 1;
foo (p);
x[i] = 2;
}
because accessability of &a[i] obviously can't be changed by any call to
free () inside foo (). But you are probably right that
__asan_poison_memory could potentially be called inside foo (however
rare it is) which would preclude this sort of optimization.
If in the future we e.g. IPA-prop propagate the nonfreeing_call_p
property through the callgraph (as in, if the function you call
is non-overridable and you know the flag for it, use it),
FYI we tried this on SPEC and some other apps but saw no performance
improvements.
-Y
