Currently, GVN can be necessary to eliminate redundant instructions in case of, for instance, GEMM and float type. This patch makes GVN be run during the cleanup.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Any reason to use NewGVN instead of (old) GVN?
I thought I had already changed the cleanup pipeline to more resemble the standard pipeline. That might still be in my devel branch and forgot to upsteam that.
I thought that NewGVN uses a stronger algorithm. If you think the old one is more reliable, let's use it.
I thought I had already changed the cleanup pipeline to more resemble the standard pipeline. That might still be in my devel branch and forgot to upsteam that.
I think it'd be great to upstream that.
It does
If you think the old one is more reliable, let's use it.
FWIW: At this point, GVN has more wrong code/etc bugs against it than NewGVN.
To be fair - There are things GVN is still better at you should consider:
- I haven't moved non-constant load/store coercion to trunk. The vast majority of cases are where the value we pull out is constant, but it is a thing gvn does better ATM. It's pretty trivial to fix if it matters, it's just not made the priority list
- GVN catches the inverse of equalities for non-branch controlling icmps, NewGVN doesn't ATM. i have a patch coming to fix this.
- GVN does PRE, NewGVN does not.
(NewGVN is really an analysis, and i have a patch to make it so. It has a full redundancy eliminator run after the analysis, but i haven't gotten around to implementing a partial one).