[PATCH] D129352: [CodeGen] Limit building time for CodeGenPrepare

[Xiang Zhang via Phabricator via llvm-commits]

xiangzhangllvm added a subscriber: david-arm.
xiangzhangllvm added a comment.

In D129352#3643924 <https://reviews.llvm.org/D129352#3643924>, @xiangzhangllvm wrote:

> In D129352#3642318 <https://reviews.llvm.org/D129352#3642318>, @yubing wrote:
>
>> if GEP and Gather/Scatter are not in the same bb, we don't do optimize GEP in the first round. When it is second round and GEP and Gather/Scatter are put in the same bb, your code will let the GEP's optimization not happen.
>
> Let me try to find a test case. (I default enable BuildTimeLimit in my local, didn't meet any compiling fail test case yet.)
> I think we should go further to find here " GEP's optimization is Mandatory" is make sense or not.

I didn't encounter Gather/Scatter build fails.

I did a local experiment：
Even I totally disable all then optimizeBlock, I only meet one build fail in isel for test/CodeGen/Thumb2/mve-pred-vselect.ll.
(affected with optimizeSelectInst)

  -  bool MadeChange = true;
  + bool MadeChange = false;      // let it  not do optimization at all
    while (MadeChange) {
      MadeChange = false;
      DT.reset();
      for (BasicBlock &BB : llvm::make_early_inc_range(F)) {
        bool ModifiedDTOnIteration = false;
        MadeChange |= optimizeBlock(BB, ModifiedDTOnIteration);

I am not familiar with Thumb2's ISel. I don't think it is make sense that its correctness base on such optimization.
ping the test contributor @david-arm 
(Anyway this patch didn't affect it.)


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

https://reviews.llvm.org/D129352