[PATCH] D135915: [ConstraintElim] Enable pass by default.

[Vitaly Buka via Phabricator via llvm-commits]

vitalybuka added a comment.

Different ubsan checks have different effect on the pass, but looks like -fsanitize=pointer-overflow is most significant

With just only this check we see timing like this.

  ===-------------------------------------------------------------------------===
                            Pass execution timing report
  ===-------------------------------------------------------------------------===
    Total Execution Time: 195.4380 seconds (198.3854 wall clock)
  
     ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
    93.1270 ( 48.2%)   0.7577 ( 32.9%)  93.8847 ( 48.0%)  95.2275 ( 48.0%)  ConstraintEliminationPass
    41.0259 ( 21.2%)   0.6802 ( 29.5%)  41.7061 ( 21.3%)  42.4373 ( 21.4%)  InstCombinePass
    13.8371 (  7.2%)   0.1043 (  4.5%)  13.9414 (  7.1%)  14.0983 (  7.1%)  IndVarSimplifyPass
     8.7696 (  4.5%)   0.1775 (  7.7%)   8.9471 (  4.6%)   9.0888 (  4.6%)  InlinerPass
     5.8936 (  3.1%)   0.0790 (  3.4%)   5.9726 (  3.1%)   6.0713 (  3.1%)  GVNPass

I extracted one of affected functions and running llvm-reduce on IR, I'll continue to reduce, but here intermediate result:

https://reviews.llvm.org/P8300
Run it:
opt -O2 -time-passes report.ll -o /dev/null

I see

  ===-------------------------------------------------------------------------===
                            Pass execution timing report
  ===-------------------------------------------------------------------------===
    Total Execution Time: 45.3980 seconds (46.6084 wall clock)
  
     ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
    40.9242 ( 90.3%)   0.0355 ( 40.1%)  40.9597 ( 90.2%)  41.8877 ( 89.9%)  ConstraintEliminationPass
     2.6194 (  5.8%)   0.0080 (  9.0%)   2.6274 (  5.8%)   2.7320 (  5.9%)  InstCombinePass

>From profile ConstraintSystem::eliminateUsingFM is top offender. NR.push_back(N); is executed very frequently, e.g. on the function from reproducer with ~70K IR instructions that push back called about 120M times.
Probably something is O(N^2), where N is number of labels?

Does reverting makes sense before we have a fix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135915