On Thu, 2020-11-19 at 23:41 +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > As mentioned in the PR, the previous PR91029 patch was testing > op2 >= 0 which is unnecessary, even negative op2 values will work the > same, > furthermore, from if a % b > 0 we can deduce a > 0 rather than just a > >= 0 > (0 % b would be 0), and it actually valid even for other constants > than 0, > a % b > 5 means a > 5 (a % b has the same sign as a and a in [0, 5] > would > result in a % b in [0, 5]. Also, we can deduce a range for the other > operand, if we know > a % b >= 20, then b must be (in absolute value for signed modulo) > > 20, > for a % [0, 20] the result would be [0, 19]. > > The following patch implements all of that, bootstrapped/regtested on > x86_64-linux and i686-linux, ok for trunk? > > 2020-11-19 Jakub Jelinek <ja...@redhat.com> > > PR tree-optimization/91029 > * range-op.cc (operator_trunc_mod::op1_range): Don't require > signed > types, nor require that op2 >= 0. Implement (a % b) >= x && x > > 0 > implies a >= x and (a % b) <= x && x < 0 implies a <= x. > (operator_trunc_mod::op2_range): New method. > > * gcc.dg/tree-ssa/pr91029-1.c: New test. > * gcc.dg/tree-ssa/pr91029-2.c: New test. > > --- gcc/range-op.cc.jj 2020-11-19 20:09:39.531862131 +0100 > +++ gcc/range-op.cc 2020-11-19 20:44:24.507774154 +0100 > @@ -2637,6 +2637,9 @@ public: > virtual bool op1_range (irange &r, tree type, > const irange &lhs, > const irange &op2) const; > + virtual bool op2_range (irange &r, tree type, > + const irange &lhs, > + const irange &op1) const; > } op_trunc_mod;
Should these various overrides of vfuncs be labeled "OVERRIDE" rather than "virtual", to use the override specifier? In fact, given that we now require C++11, presumably we can spell that as "override" and lose the macro. Dave
