[all-commits] [llvm/llvm-project] 16743c: [CodeGen] Limit building time in CodeGenPrepare fo...

xiangzh1 via All-commits all-commits at lists.llvm.org
Tue Sep 6 19:10:36 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 16743c953441e8a5aad53069e9a13b14ff5ac09a
      https://github.com/llvm/llvm-project/commit/16743c953441e8a5aad53069e9a13b14ff5ac09a
  Author: Xiang1 Zhang <xiang1.zhang at intel.com>
  Date:   2022-09-07 (Wed, 07 Sep 2022)

  Changed paths:
    M llvm/lib/CodeGen/CodeGenPrepare.cpp
    M llvm/test/CodeGen/AArch64/and-sink.ll
    M llvm/test/CodeGen/X86/and-sink.ll
    M llvm/test/Transforms/CodeGenPrepare/ARM/sinkchain-inseltpoison.ll
    M llvm/test/Transforms/CodeGenPrepare/ARM/sinkchain.ll
    M llvm/test/Transforms/CodeGenPrepare/X86/gather-scatter-opt-inseltpoison.ll

  Log Message:
  -----------
  [CodeGen] Limit building time in CodeGenPrepare for huge function

Details:

Currently CodeGenPrepare is very time consuming in handling big functions.

Old Algorithm :
It iterate each BB in function, and go on handle very instructions in BB.
Due to some instruction optimizations may affect the BBs' dominate tree.
The old logic will re-iterate and try optimize for each BB.

Suppose we have a big function with 20000 BBs, If we handled the last BB
with fine tuning the dominate tree. We need totally re-iterate and try optimize
the 20000 BBs from the beginning.

The Complex is near N!

And we really encounter somes big tests (> 20000 BBs) that cost more than 30
mins in this pass. (Debug version compiler will cost 2 hours here)

What this patch do for huge function ?
It mainly changes the iteration way for optimization.

1 We do optimizeBlock for each BB (that is same with old way).
And, in the meaning time, If BB is changed/updated in the optimization, it will
be put into FreshBBs (try do optimizeBlock again).
The new created BB at previous iteration will also put into FreshBBs.

2 For the BBs which not updated at previous iteration, we directly skip it.
Strictly speaking, here may miss some opportunity, but the probability is very
small.

3 For Instructions in single BB, we do optimizeInst for each instruction.
If optimizeInst change the instruction dominator in this BB, rather than break
and go back to optimize the first BB (the old way), we directly iterate
instructions (to do optimizeInst) in this updated BB again (the new way).

What this patch do for small/normal (not huge) function ?
It is same with the Old Algorithm. (NFC)

Reviewed By: LuoYuanke

Differential Revision: https://reviews.llvm.org/D129352




More information about the All-commits mailing list