On 11/07/2016 03:02 AM, Richard Biener wrote:
On Sat, Nov 5, 2016 at 3:30 AM, Jeff Law <l...@redhat.com> wrote:
On 11/04/2016 02:07 PM, Marc Glisse wrote:
Hello,
since we were discussing this recently...
The condition is copied from the existing 0 % X case, visible in the
context of the diff.
As far as I understand, the main case where we do not want to optimize
is during constexpr evaluation in the C++ front-end (it wants to detect
the undefined behavior), and with late folding I think this means we
only need to care about an explicit 0/0, not about X/X where X would
become 0 after the simplification.
And later, if we do have something like X/0, we could handle it the same
way as we currently handle *(char*)0, insert a trap after that
instruction and clear the following code, which likely gives better code
than replacing 0/0 with 1.
Yup. I'd prefer to insert a trap if we ultimately expose a division by zero
-- including cases where that division occurs as a result of a PHI arg being
zero and the PHI result being used as a denominator in a division
expression.
It ought to be extremely easy to detect & transform that case (and probably
warn for it too).
We have gimple-ssa-isolate-paths.c for that, right?
Right. I was thinking about instrumenting for it today to see if it's
worth any effort. It shouldn't take more than a few minutes once I
refamiliarize myself with isolate-paths.
jeff
