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).
I'm leaving the actual review to Richi.
jeff
