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