Re: [RFC] UBSan unsafely uses VRP

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Nov 12, 2014 at 12:58:37PM +0300, Yury Gribov wrote:
> On 11/12/2014 11:45 AM, Marek Polacek wrote:
> >On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote:
> >>On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
> >>>>There are also some unsafe code in functions
> >>>>ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check
> >>>>which uses get_range_info to reduce checks number. As seen before vrp usage
> >>>>for sanitizers may decrease quality of error detection.
> >>>
> >>>Using VRP is completely intentional there, we don't want to generate too
> >>>slow code if you decide you want to optimize your code (for -O0 VRP isn't
> >>>performed of course).
> >>
> >>On the other hand detection quality is probably more important than
> >>important regardless of optimization level. When I use a checker, I don't
> >>want it to miss bugs due to overly aggressive optimization.
> >
> >Yes, but as said above, VRP is only run with >-O2 and -Os.
> 
> Hm, I must be missing something.  99% of users will only run their code
> under -O2 because it'll be too slow otherwise.  Why should we penalize them
> for this by lowering analysis quality?  Isn't error detection the main goal
> of sanitizers (performance being the secondary at best)?

But, if -O0 isn't too slow for them, having unnecessary bloat even at -O2
is bad the same.  But not using VRP at all, you are giving up all the cases
where you know something won't overflow because you e.g. sign extend
or zero extend from some smaller type, sum op such values, and something
with constant, or you can use a cheaper code to multiply etc.
Turning off -faggressive-loop-optimizations is certainly the right thing for
-fsanitize=undefined (any undefined I'd say), so are perhaps selected other
optimizations.

	Jakub