[PATCH] Optimize UBSAN_NULL checks, add sanopt.c

[Yury Gribov]

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