https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84321
--- Comment #12 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #11) > (In reply to rsand...@gcc.gnu.org from comment #10) > > I'd tried doing this in set_nonzero_bits first, before adding > > intersect_range_with_nonzero_bits. See > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00095.html for why it didn't > > work. > > IMHO that is a risk of all the VRP changes that some case will regress, the > more important question is how much it will help in general, and I think it > would. Yeah I'd hoped so too, but... > If it is only done in this special case, other passes can't benefit from the > more accurate range info. ...when I did a comparison of the testsuite assembly output on a range of targets, I didn't find any examples of things benefiting outside of split_constant_offset, but quite a few regressions caused by trying to interesect a VR_ANTI_RANGE with a reduced VR_RANGE. The testsuite isn't the most representative codebase around, but still, it suggests that we'd need to add some special cases elsewhere to compensate.
