https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Untested WIP patch. Still no idea how to handle the build_range_check stuff
> at GIMPLE, that function is pretty huge. Shall I just always generate the
> cast to utype and (acmp (minus (convert:utype @0) { lo; }) { himinuslo; })
> after doing the etype/utype computation and verification in (with {...}) and
> hope rest of match.pd optimizes that or add matchers for the various
> optimizations in there?
It seems reasonable to me to always emit something of the form (le (minus
(convert:utype @0) cst) cst) here (or maybe even a bit_and of comparisons with
the extremities as an intermediate step), and add a separate (rather long)
transformation that recognizes special cases of this pattern like (x-42u)<=-43u
(aka x>=42u). I am slightly concerned about unsafe things happening to
pointers, but I probably shouldn't be.
