This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/68398] [6 Regression] coremark regression due to r229685
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 23 Jan 2016 09:16:01 +0000
- Subject: [Bug tree-optimization/68398] [6 Regression] coremark regression due to r229685
- Auto-submitted: auto-generated
- References: <bug-68398-4 at http dot gcc dot gnu dot org/bugzilla/>
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.