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. > 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 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 and thus disregard the special-case of x == INT_MIN which means we do not want to lose that information in exchange for nothing. > 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.
