avoiding removal of -ftrapv libcalls in RTL optimization

Richard Guenther richard.guenther@gmail.com
Mon Sep 17 09:21:00 GMT 2007

On 9/17/07, Ken Raeburn <raeburn@raeburn.org> wrote:
> I've been looking into this problem a little bit.  There are tree
> optimizations that cause cases like "a + 4 - 4" to generate RTL that
> never has the conditional traps in it (when it should probably trap
> if a+4 exceeds <type>_MAX), but RTL optimizations can make some of
> the emitted libcalls to __addv?i3 or __mulv?i3 go away too.
> I noticed in the generated RTL for my test cases, before the call is
> removed, it's shown in the dump files as a "call_insn/u", that is, a
> call to a pure or const function.  I don't think that's accurate for
> a function that may abort.
> An approach I've been experimenting with, which seems to be helping, is:
>   - Add a CONST_P field to optab structures, set in init_optab,
> cleared in init_optabv.
>   - If CONST_P is set, call emit_library_call_value with LCT_CONST as
> we do now.
>   - If CONST_P is not set, use LCT_NORMAL instead.
>   - In dead_libcall_p, find the call_insn, if any; if it does not
> have the const-or-pure flag set, return false, so we keep the call.
> If it is set, or we don't find it, keep going as before.
> It's working in my simple test cases.  I've successfully done a
> bootstrap and "make -k check" pass based on trunk revisions 128508 on
> my x86 Mac; it passes the stage2/stage3 comparison, the new test case
> (checking that __addvsi3 and __mulvsi3 calls are retained) fails with
> the trunk but passes with my patch, and the other test results are
> the same.
> I noticed init_optabv is used to set up sdivv_optab, which appears to
> be unused (and probably should be removed, but as a separate patch).
> The other init_optabv cases all look like ones where this change
> would be correct.
> Comments?  (BTW, I don't have check-in access these days, but
> assignment papers should be on file.)

Which of my observations in PR19020 comment #5 does this fix?  I guess
the first one?

In general I think it is not worth in trying to fix -ftrapv, I believe we should
instead deprecate and kill it.  It is somewhat ill-defined as you noticed and
lacks trap on conversions and also on division and shifts.

What we certainly would need is some more testcases for the feature.
(I'd put your testcase in gcc.target/i386).

Btw., can you use -p for the patches please?


> Ken
>         * optabs.h (struct optab): New field CONST_P.
>         * optabs.c (init_optab, init_optabv): Initialize it.
>         (expand_binop, expand_unop): If CONST_P field of optab is clear,
>         use LCT_NORMAL instead of LCT_CONST when emitting libcall.
>         * cse.c (dead_libcall_p): If preceding call_insn isn't flagged
>         as const or pure, return false.

More information about the Gcc-patches mailing list