Address comment.

Update test case.

address comments.

address comments.

address comment.

Add docs.

Add test for virutal function.

start a new diff to make nomerge attribute a function attribute as well as a statement attribute.

Adrian said he will work on this, so I abandoned this.

• fix existing failed testcase.
• add new testcases for npm and lpm.
• add comments.

In D92623#2438080, @asbirlea wrote:

According to: https://clang.llvm.org/docs/AttributeReference.html#nomerge, the existance of the attribute should prevent call site merging, so the change makes sense.
However, in the test example then, if there was branching and two @f calls inside @bar, it would be correct to merge the @f call sites (no attribute preventing that inside) when processing @bar. But after inlining, that's no longer allowed if the attribute is distributed to all callsites inside the function.
This is a contradiction that needs clarification from folks more familiar with the Inliner.

• 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.