[PATCH] D84547: [ConstraintElimination] Add constraint elimination pass.

Sat Aug 15 08:05:18 PDT 2020

fhahn added a comment.

In D84547#2216607 <https://reviews.llvm.org/D84547#2216607>, @spatel wrote:

> We definitely stretch instcombine beyond the basics to try to reduce icmps, so if we can do that more efficiently here, that seems like a win.
> Do you know if http://bugs.llvm.org/PR47091 could (eventually) be handled here?

Initially we only keep the current constraints for basic block level granularity, but this could be changed in the future to make it track & query per instruction. For the example in PR47091, we can check if any of the constraints become redundant. It would require extending the scope of the pass to consider re-writing a set of compares to a reduced set, instead of only removing known conditions. I think that's certainly possible in the future, once the initial implementation settled in. Also, the pass itself is quite small, so it should be easy to iterate/change/rewrite/extend in tree.

> Is there any initial compile-time data?

With a few additional changes to decompose more constructs, it doesn't look too bad, O3 <https://reviews.llvm.org/owners/package/3/> +0.23% geomean, ReleaseThinLto + 0.36% (http://llvm-compile-time-tracker.com/compare.php?from=6a821908f49019f3180c640cd6ddf570aceaca78&to=2569b43f8184c94b878060cb23455e397f2ef8d9&stat=instructions). That's with plenty of tuning opportunities in the constraint-system implementation. There seems to be quite a big regression for a case with `-g` which I need to check out though.

One additional caveat is that it currently only handles information from unsigned compares. If we can prove that a value is non-negative, it should also be possible to include info from signed compares. But we would probably need to maintain a separate set of constraints for signed compares.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84547/new/

https://reviews.llvm.org/D84547