https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106138
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #1) > So we're seeing > > b1_8 = x_7(D) == 4; > # RANGE [0, 3] NONZERO 3 > _3 = x_7(D) & 3; > b2_9 = _3 != 0; > _5 = b1_8 & b2_9; > > and fail to optimize that. It somewhat looks like "relations" (on x_7), but > I'm not sure if suitable to handle for ranger. > > Adding something in match.pd might be possible - the key is of course that > both b1 and b2 are derived from the same value. I think we already have > a pattern looking at not intersecting nonzero bits. Its not suitable yet anyway. theres an order of indirection in that any relation is based on whether b1_8 and b2_9 are both 1 or both 0... If there was a branch we start to pick up information on the edges... but without an edge using _5, we don't yet try to paw back the same way. perhaps we could optimize &/&& and |/|| to check if one of the operands doesnt matter.. ie, if b1_8 is 1, then check if b2_9 is always 1 with the range of x_7([4,4]), likewise if b1_8 is 0, then b2_9 doesnt matter. so we can simplify this to _5 = b1_8 it seems like something we could do with simplify_using_ranges quite easily by utilizing gori perhaps? easy enough to pick up a range for b2_9 based on the range of x_7 from b1_8 == [1,1]
