On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek <pola...@redhat.com> wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch. It really is dependent on the generic
> > parts, when commiting, I'll put both parts together.
>
> Just a question (I will review the patch later today): shouldn't
> generic parts also work without new target patterns and use __addv*
> stuff from libgcc when patterns are not present?
They work (except for multiplication checking with widest supported mode, to
be supported later), but they can't use __addv* and co., because those
functions __builtin_trap () on overflow, while for
-fsanitize=signed-integer-overflow, if we wanted a library solution, we'd
need library functions that would return us both result and bool whether
overflow happened. As addition/subtraction/negation overflow checking
is short and easily inlinable, that is done always inline now, and
for multiplication the code right now expands WIDEN_MULT_EXPR if possible.
Note that using get_range_info the generic expansion could be supposedly
improved, for add/sub we right now at runtime compare op1 against zero
and do one thing if it is negative and another if non-negative.
If VRP info tells us that either op0 or op1 is known to be non-negative
or known to be negative, we could just simplify the expansion.
I guess similarly for the multiplication, but after all, I think the VRP
info could be useful even for normal multiplication expansion, e.g. if
we want to do a WIDEN_MULT_EXPR, but know that given the operand ranges
we can actually do a MULT_EXPR only and then just sign/zero extend the
result, that will likely be cheaper.
If VRP figures out there will never be an overflow, then we already optimize
the UBSAN_* internal builtins into normal PLUS_EXPR etc.
Jakub
