• sync NPM with LPM.
• use PreInlineThreshold flag value instead of hardcode number.

In D92349#2425794, @ldionne wrote:

@zequanwu In the future, please refrain from committing to libc++ or libc++abi unless you have approval of the libcxx or libcxxabi review group. There's a reason why that group is added as a "blocking reviewer", it's because you should wait for it to be green before proceeding.

address comment.

In D91673#2401578, @xur wrote:

This is probably OK for -Os (SizeLevel == 1), but we need to be careful with Oz (SizeLevel == 2).
We already know that enabling preinliner in general will reduce size -- as the preinliner is pretty conservative. But there will be cases size will be increased.

I would like more test results (like bootstrap clang) before committing.

In D91747#2423960, @rnk wrote:

If we believe the standard says that the compiler is supposed to set __STDCPP_THREADS__, then I think the libc++ #error needs to be adjusted. libcxxabi, or any other client, should be able to define _LIBCPP_HAS_NO_THREADS, and it should work, even if the compiler thinks they are allowed.

Update tests.

Add ThreadModel to LangOptions and remove it from CodegenOption.

Add a test case.

update wrong diff.

Address comments.

Address comments.

include correct header

In D89812#2354862, @stella.stamenova wrote:

load-pdb is still failing on the Windows bot. Can you please commit a fix soon or revert the change?

In D89812#2354862, @stella.stamenova wrote:

load-pdb is still failing on the Windows bot. Can you please commit a fix soon or revert the change?

In D89812#2354320, @jankratochvil wrote:

It has regressed buildbots:

SymbolFile/NativePDB/load-pdb.cpp
lldb-x86_64-fedora: http://lab.llvm.org:8014/#/builders/14/builds/1006
lldb-x86_64-debian: http://lab.llvm.org:8011/#/builders/68/builds/782

Address comments.

Hi, this seems like causing assertion failure: Assertion Result && "Could not evaluate expression"' failed. at https://bugs.chromium.org/p/chromium/issues/detail?id=1142009

Fix test cases which failed on Windows.

Address comments.

Address some comments.

• address comments.
• add tests.
• move loadPDBFile from SymbolFileNativePDB.cpp to ObjectFilePDB.cpp and use it to create unique_ptr of PDBFile so that we can move it around.

elaborate CHECK

• Add GetArchitecture method, similar to ObjectFilePECOFF
• Add a test case.

address comment

In D89590#2342497, @aeubanks wrote:

I'd say either revert https://github.com/llvm/llvm-project/commit/cdd006eec9409923f9a56b9026ce2cb72e7b71dc, or in FoldTwoEntryPHINode() check that the option is set and that the OptForFuzzing attribute is not set (same with simplifyCondBranch()). I guess I'd slightly prefer the second option as to not totally revert the original commit.

How can I start lldb at specified path so that target symbols add bar.pdb could find the pdb path? (For testing)

In D89590#2335885, @lebedev.ri wrote:

In D89590#2335864, @aeubanks wrote:

In D89590#2335840, @lebedev.ri wrote:

Why is this NPM specific?

This is something the legacy pass did but was not properly ported to the NPM pass.

Right. But why is this PM-specific at all, why aren't the folds themselves guarded with that?

update test.

Put a fix here: https://reviews.llvm.org/rG19ae9b6e21e2491debeb910e2c541be9796f1b13

• Add a test case
• Fix broken test cases caused by -path-equivalence= not working correctly with . and .. in paths.

sorry, I didn't notice that.

Will put the refactor part to a separate NFC commit.
Reland this as fix at D88456 seems work. (https://bugs.chromium.org/p/chromium/issues/detail?id=1130780#c18)

Split changes on .cg_profile to another patch D88456.

For symbols haven't seen, just set them to external not weak external.

Update. Don't emit CGProfileEntry if function has dll import storage class.

In D88127#2291320, @rnk wrote:

I'm saying the fix belongs in TargetObjectFileLoweringImpl.cpp, which is the point where we translate from IR to assembly. We can't fix this after producing assembly, because we don't know what symbols are marked dllimport at that point.

In D88127#2291167, @rnk wrote:

However, I would prefer to move the check into CodeGen, so that if we receive some IR that has edges like this, we don't emit an object file that cannot be linked.