[Bug tree-optimization/95801] New: Optimiser does not exploit the fact that an integer divisor cannot be zero

[Bug tree-optimization/95801] New: Optimiser does not exploit the fact that an integer divisor cannot be zero

[felix.von.s at posteo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801

            Bug ID: 95801
           Summary: Optimiser does not exploit the fact that an integer
                    divisor cannot be zero
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: felix.von.s at posteo dot de
  Target Milestone: ---

int always1(int a, int b) {
    if (a / b)
        return b != 0;
    return 1;
}

The function above should be possible to optimise to a constant 1, as integer
division by zero is undefined. I’m surprised this isn’t caught already; it
seems like very low-hanging fruit.

In case someone wants to claim there is no value to be gained from this, this
is where it came up:

#define SIGNUM(value) ({ \
        __auto_type _value = (value); \
        (__typeof__(_value)) ((_value > 0) - (_value < 0)); \
    })

#define DIV_FLOOR(a, b) ({ \
        __auto_type _a = (a); \
        __auto_type _b = (b); \
        (_a / _b) - ((SIGNUM(_a) != SIGNUM(_b) ? _a % _b : 0) != 0); \
    })

For unsigned types, DIV_FLOOR(a, b) should compile to the same code as
truncating division (a / b), but unless a statement to the effect of (b == 0 ?
__builtin_unreachable() : (void) 0); is inserted before the division, DIV_FLOOR
will generate considerably longer code, at least on x86.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Except when dereferencing a pointer (?), gcc seldom uses an operation to derive
properties on the operands, it mostly derives properties on the result. That's
in large part because the information you are getting on the operands is only
valid in some regions, not for the whole life of the SSA_NAME (in if(y!=0)x/y;
the division obviously doesn't allow to remove the earlier test for y!=0)
There could be many cases:
x/y => y is not 0
i+1 => i is not INT_MAX
x/[ex]4 => the last 2 bits of x are 0
ptr+n or *ptr => ptr is not a null pointer

There is code in isolate-path to handle operands that are potentially 0, but I
think that's only when we see x / PHI<d, 0>, not for a "normal" divisor.

VRP works around the issue by creating extra SSA_NAMEs for the regions where we
know more about a variable, but it only does it for branches like if(x<10),
doing it for the operands of every operation would be too costly.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I have a patch exploiting this but it faces some correctness issues in the
propagators where some of them instantiate the assumptions before simplifying
the stmts themselves.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48768&action=edit
prototype

Here is the WIP patch, work is suspended.  There may be a duplicate bug about
this.