https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
And as it turns out, if this is tested with the trunk, things have actually
improved again -- because I fixed the bit-test regression in the x86 backend.
I get 209 million I refs for the main benchmark function.
If I allow creation of irreducible loops, then I get down to 207 million I
refs. So the core issue is still unresolved.
My first thought was to allow creation of irreducible loops in the calls after
the loop optimizer had been run. But that's not helping.
I'll have to look further next week. But as it stands right now, all the
components are working as they are expected to work AFAICT. I don't offhand
see a heuristic that would sanely allow us to create the irreducible loop in
VRP1 for this case without doing it for many others where it's considered
undesirable.
