NewGVN was recently committed and a few minute ago I added a flag to
enable the new experimental pass.
For the brave soul, passing `-mllvm -enable-newgvn` should do the
trick. We'll be happy to receive bug reports to analyze/fix, bonus
point if they contain a synthetic/reduced testcase.
Open a bug linked to https://llvm.org/bugs/show_bug.cgi?id=30995 would
be probably best so that all the people working on NewGVN will have
visibility, but I'm aware there are issues with bugzilla registration
disabled recently so if you have issues/don't have an account feel
free to shoot me a mail directly and I'll open a bug on your behalf.
Looking forward to hearing from you,
I just fixed a significant bug accidentally ported from the branch, so make your llvm is synced past r290549 before you give this a try.
I’m curious if the test-suite running cleanly with this flag?
(That would be a first step before wider testing).
Also: does clang bootstrap and pass the tests (and builds the test-suite correctly?).
I assume that this passes all the lit/lnt test cases on the platform that the developers work on. It causes 31 lnt test case failures on PPC. I’ve opened a bug with the one that is easiest to reduce.
Also, I’m happy to assist by providing any further PPC specific information you require regarding this.
These are all caused by a set of failures to properly mark memory users as changed in some cases, and to initialize the memory operand equivalence table properly.
I’m thinking how best to solve it.
In the meantime, reverting the store equivalence changes should fix most of it (there is one other bug in updateReachableEdge that won’t fix, where it misses marking memoryphi’s)
(and to be clear, reverting it would just hide the bugs pretty well, they’d fix it)
I think i have a good way of fixing this properly, patch coming.
once it’s upstream I can re-run the testing and do a bootstrap/test as well if you’d like.
Yes, I run this regularly.