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 ? >> 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 ? > 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 ? >> How to expand (type of x) ABSU_EXPR (x) to rtl ? >> >> Do we have to add a new naming pattern absu ? > > As on RTL 'abs' has well-defined behavior on wrapping we can just use > that. Got it. (type of x) ABSU_EXPR (x) have same semantic with RTL 'abs'. > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
