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

[Bruno Cardoso Lopes]

Hi Philip,

> Drive by comment - this might be completely wrong.


Thanks for the comments :-)

> 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?


I don't have exact numbers, but many calls pile up and if you tweak the 'Limit' value in the patch you see how fast it grows. I may clarify that in the comments, but the problem is not that dominates or isPotentiallyReachable are expensive per-se, but the piled up number of calls to those greatly increase the compile time if we have to walk a large number of instructions.

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


Because 'dominates' needs an exact answer, it returns TooExpensive instead of 'true' or 'false'.

> 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.


Note that what I'm actually trying to achieve here is a fast path for:

  if (BeforeHere != I && DT->dominates(BeforeHere, I) &&
      !isPotentiallyReachable(I, BeforeHere, DT))

Hence, if 'BeforeHere' dominates 'I', we don't actually need to do any BB walk like what it's done in 'isPotentiallyReachable', and early prune the search in case we're on a entry block or don't have successors. Otherwise we must continue the search, because the BB may be in a Loop, etc.

> 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.


This looks like a really good idea but that would also require more intrusive changes to the current implementation without the actual guarantee that it yield benefits.

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


Thanks again! :D


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7010

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/