User Details
- User Since
- Sep 24 2019, 12:21 AM (209 w, 3 d)
Aug 1 2023
Jul 25 2023
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.
Jul 24 2023
Jul 16 2023
Jun 7 2023
@jcranmer-intel thank you for the review
Jun 6 2023
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
Jun 5 2023
update llvm/test/Other/cfg-printer-filter.ll to test optnone
Jun 4 2023
Apr 25 2023
kindly ping @jcranmer-intel
Apr 19 2023
Apr 13 2023
Aug 22 2022
May 5 2022
rebase
Apr 25 2022
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.
Apr 24 2022
Apr 18 2022
@arsenm could you please submit for me? I don't have the permission. Thank you.
Apr 14 2022
remove OverrideFlatAS, move test into X86 folder
Apr 12 2022
So you're claiming InferAddressSpaces asserts for x86? Can you add a test?
Apr 10 2022
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?
Apr 8 2022
Mar 31 2022
RISCV LIT fails should not be related to this patch. Today I've verified this patch with check-llvm on latest llvm.
Mar 24 2022
fix lit merge conflict
Mar 23 2022
move OptimizerEarlyEPCallbacks after RecomputeGlobalsAAPass
Aug 9 2021
Jul 28 2021
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
Jul 7 2021
Jul 5 2021
Mar 30 2020
Mar 29 2020
Mar 14 2020
Sep 24 2019
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.