[PATCH] D44282: [PR16756] JumpThreading: explicitly update SSA rather than use SSAUpdater.

Daniel Berlin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 8 18:14:45 PST 2018


dberlin added a comment.

So, FWIW:
It's definitely possible to make the  SSAUpdater rewrite faster in bulk insertion.  I just never bothered because it wasn't used that way :)
You will never make it as fast as exploiting the problem structure, but it could be made a *lot* faster.

As for this one:
There are approaches to reuse a lot of the phi placement computation in bulk. It's also possible to close IDF recomputation under DT update (IE incrementally recompute IDF).

You can see an example of something like that in the TDMSC algorithms here:https://dl.acm.org/citation.cfm?id=1065890

It only relies on the DJ graph, and it's possible, at maximum, to invalidate only the merge sets as DT changes.
(We'd need to get info from DT about what happened during an update, but that seems easy enough)

All depends how far down this rabbit hole you want to go.

As for the pass-specific vs bulk updating, yeah, this is the eternal debate.
JT itself doesn't make too many types of transforms, and i wonder if you could just verify them all working with the ssa updater with all the types of cfgs or something.
(This would be fragile in other ways, but at least would give you confidence the thing works)

I think it also depensd on how much faster you can make the generic bulk updater. For example, if you get it to 0.9x the speed of the impl you have here, i suspect that's plenty good enough.
 But i'm also not the one doing the work :)


Repository:
  rL LLVM

https://reviews.llvm.org/D44282





More information about the llvm-commits mailing list