In D155417#4552384, @arsenm wrote:

MachineDominanceFrontier::addToFrontier.

Where is this used?

The regression was an assert failure in IndVarSimplifyPass. The LIT is over-simplified and doesn't have the assert.
I just find out that the regression only exists in non-opaque-pointer mode. So this fix is not needed.
Sorry for the noise. I should have tested the opaque pointer mode.

@jcranmer-intel thank you for the review

add test of global and poison value, add comment of 'It is safe to treat TargetExtType as its layout type'

I don't have a test case of global variable with target extension type.

add load/store/constant lit test for changes in ExecutionEngine.cpp

update llvm/test/Other/cfg-printer-filter.ll to test optnone

kindly ping @jcranmer-intel

rebase

In D124355#3471198, @dmgreen wrote:

Can you just have getUnrollingPreferences override the UP.Threshold for your target?

Thanks for the suggestion.

Or is it that you want a specific run of the unroll pass to have a lower threshold than other runs?

Yes, our pipeline contains several calls of LoopUnroll pass with different thresholds, so I think getUnrollingPreferences or overriding command line option wouldn't work.

In D124355#3471091, @fhahn wrote:

Do you have any plans to add a user of the new Threshold option upstream

@arsenm could you please submit for me? I don't have the permission. Thank you.

remove OverrideFlatAS, move test into X86 folder

So you're claiming InferAddressSpaces asserts for x86? Can you add a test?

isNoopPtrIntCastPair in lib/Transforms/Scalar/InferAddressSpaces.cpp calls isNoopAddrSpaceCast, but the two arguments might be the same. I notice isNoopAddrSpaceCast in other targets don't have such assert, so I remove this assert in X86 target.
Do you think we should check address spaces are not the same prior to isNoopAddrSpaceCast callsite in isNoopPtrIntCastPair?

RISCV LIT fails should not be related to this patch. Today I've verified this patch with check-llvm on latest llvm.

fix lit merge conflict

move OptimizerEarlyEPCallbacks after RecomputeGlobalsAAPass

The issue is that DefaultOptions is special and delay-processed in CommandLineParser::ParseCommandLineOptions. Suppose the main thread calls llvm:🆑:ParseCommandLineOptions, then DefaultOptions is processed but it is not cleared after processing.
Multithreads calling setCommandLineOpts in clang/lib/CodeGen/BackendUtil.cpp will have race condition on repeated and redundant processing of DefaultOptions. This race condition (SC->OptionsMap) is also explained in https://reviews.llvm.org/D99652

We see error "clang (LLVM option parsing): for the --pgo-warn-misexpect option: may only occur zero or one times!" when clang::CompilerInvocation::CreateFromArgs and clang::ExecuteCompilerInvocation are called twice.