[PATCH] [CaptureTracking] Avoid long compilation time on large basic blocks

Philip Reames listmail at philipreames.com
Thu Jan 15 17:40:02 PST 2015

Drive by comment - this might be completely wrong.

I wouldn't expect that dominates or isPotentiallyReachable would be expensive when querying two instructions in the same BB.  At worst, it's a linear scan of the BB.  Even at 81782 instructions, that's pretty fast.  How many time is this getting called?

It would seem reasonable to push the search limit down into isPotentiallyReachable.  Not dominates unfortunately, that has to be an exact answer.

However, do you actually need to an instruction level dominance answer when the instructions are in the same BB?  Wouldn't isPotentiallyReachable take care of that?

You might be able to push your limit down into isPotentiallyReachable and just not call dominates when the def and use are in the same BB.

You might also consider looking at why those loops are slow.  Are there micro-optimizations (i.e. loop structure, iterator use, etc..) which would help a lot?  For example, you could consider advancing both iterators on every iteration to help with cases where one is near the end of the BB.  (Not sure this is actually a good idea!)

Taking a step back, you could consider grouping uses by basic block, and then trying to share work across uses in the same block.

Having said all of that, I don't actually have any *objection* to the current approach.  :)




More information about the llvm-commits mailing list