https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|tnfchris at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > That change shouldn't have caused code generation changes IIRC.
>
> That is, I would have expected RTL expansion to expand the
> division/multiplications as shifts.
I've been looking into this and PR120805
There are two changes, first one is simple,
there are some match.pd rules to optimize shifts into & for rounding down to
the nearest multiple of the VF.
These don't trigger now since we get one of the shifts as a multiplication.
I've added the missing foldings for unsigned integers. That shouldn't have
resulted in any large loss though as this is only triggered in the preheader.
The second change is that before the bounds variable didn't have any range
attached to it.
e.g.
bnd.704_180 = _181 - _132;
but now it shows
# RANGE [irange] unsigned int [1, 2147483647]
bnd.704_180 = _181 - _132;
for some reason ranges don't seem to be determined on shifts.
This additional change information causes additional foldings
to apply. in the case of PR120805 this causes it to remove
some codepaths that are not reachable and results in the
removal of instructions, hende the change in asm output.
The range above is correct, due to the loop versioning that's happening
in the loop.
I suspect that a similar thing is happening here and it's perturbing something
in the backend. At the GIMPLE level the changes look sound.
So I'll need to ask someone with some more knowledge of the x86 backend
to take a look, as this seems target expansion specific.
