On Mon, Jul 3, 2017 at 4:28 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Joseph, Jeff, Thanks a lot for your comments. I'll work on updated version and post it (hopefully) soon. -Y
