On 07/03/2017 08:52 AM, Joseph Myers wrote: > I'd expect much more thorough testcases here, both for cases that get > optimized and cases that don't. You're only testing comparisons with > zero. There should be comparisons with other values, both integer and > noninteger, both within the range for which optimizing would be valid and > outside it, both inside the range of the integer type and outside it. > (To the extent that you don't optimize some cases that would be valid to > optimize as discussed in that PR, XFAILed tests, or deferring adding > tests, would be reasonable. But each case identified in that PR as not > valid to optimize, or only valid to optimize with -fno-trapping-math, > should have corresponding tests that it's not optimized.) > > Since SCALAR_FLOAT_TYPE_P includes decimal floating-point types, tests > with those are desirable as well (in gcc.dg/dfp or c-c++-common/dfp, I > suppose). > Agreed. I think with better testing this should be able to move forward after the technical review. It's not terribly different conceptually than the code in DOM/VRP, except that Yuri's changes work on floating point types.
I'm pretty sure DOM's bits could be replaced with a suitable match.pd pattern (which IMHO would be a small improvement across multiple axis). VRP would be more difficult as the VRP implementation depends on getting the value range of the RHS of the conditional. Jeff
