https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 8 Jun 2016, shiva0217 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 > > --- Comment #19 from Shiva Chen <shiva0217 at gmail dot com> --- > 2016-06-06 15:41 GMT+08:00 rguenther at suse dot de > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 > > > > --- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- > > On Mon, 6 Jun 2016, shiva0217 at gmail dot com wrote: > > > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 > >> > >> --- Comment #17 from Shiva Chen <shiva0217 at gmail dot com> --- > >> Hi, Richard > >> > >> Thanks for the explanation :) > >> > >> So the transformation (short)abs((int)short_var) -> abs (short_var) > >> > >> should guard by TYPE_OVERFLOW_WRAPS > >> > >> because when TYPE_OVERFLOW_WRAPS is true, signed operation could wrap > >> around.(ABS_EXPR in gimple could wrap around and rtl abs already modulo) > > > > it _does_, not _could_ wrap around. > > > >> > >> Therefore, the transformation is valid when TYPE_OVERFLOW_WRAPS is true. > > > > Yes. > > > >> It seems the last update of Matthew's patch in > >> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00433.html > >> still make sense. > >> > >> Why would it be dropped, or there're still something we should consider ? > > > > I don't see any "update" of the patch and the patch directly linked > > is wrong. > > > >> If we implement ABSU_EXPR, when should transfer > >> ABS_EXPR (x) -> (type of x) ABSU_EXPR (x) ? > > > > When it makes sense to us to avoid introducing undefinedness into our IL > > without losing the advantage of the undefinedness of ABS on INT_MIN. > > What's the advantage of the undefinedness of ABS on INT_MIN ? The advantage is that value-range analysis can conclude that ABS (x) >= 0. Otherwise it can just conclude its value-range is ~[INT_MIN+1, -1]. > >> Could we define like if (!TYPE_OVERFLOW_WRAPS) then transfer ABS_EXPR (x) > >> -> > >> (type of x) ABSU_EXPR (x) in match.pd ? > > > > If we do that unconditionally then we can as well simply say we always > > Does that mean we should transfer all of the ABS_EXPR (x) to (type of > x) ABSU_EXPR (x) ? > > > treat ABS_EXPR as having defined behavior on overflow. I think it's > > useful to value-range analysis that we can assert that abs(x) >= 0 > > Dose it mean ABSU_EXPR (x) >=0 ? Yes, of course - all unsigned values are >= 0. But you'd transfer int a = ABS_EXPR (b); to int a = (int) ABSU_EXPR (b); which has, due to implementation-defined behavior of unsigned -> int conversion, a value range of ~[INT_MIN+1, -1] for a and [0, -INT_MIN] for ABSU_EXPR (b). > > and thus disregard the special-case of x == INT_MIN which means we > > do not want to lose that information in exchange for nothing. > > I'm not familiar with value-range analysis and I try to trace > tree-vrp.c recently. > Could you guide me which process in tree-vrp.c could have benefit with > abs(x) >= 0 ? Further analysis of value ranges based on abs(x) and any range tests in user code that didn't consider the special case.
