Re: [PATCH] Optimize UBSAN_NULL checks, add sanopt.c

[Jakub Jelinek <jakub at redhat dot com>]

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.

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), things
would still work unless you LTOed libasan together with your app
(to make that work you'd probably want to add asm volatile to
those calls, but doing it now would be very premature, or
make __asan_*poison_memory_region a builtin that would be handled
explicitly).

Anyway, what I mean, ATM most of the calls are still going to be considered
possibly freeing, and it will be pretty much the same calls that are
considered as potentially calling __asan_poison_memory_region, so the
optimization wouldn't change much.

	Jakub