Reviewers: evandro, qcolombet, paquette, MatzeB, arsenm

Reviewed By: paquette

Differential Revision: https://reviews.llvm.org/D70566

Summary:
If the index returns duplicated refs, it will trigger the assertion in
BuildRenameEdit (we expect the processing position is always larger the
the previous one, but it is not true if we have duplication), and also
breaks our heuristics.

This patch make the code robost enough to handle duplications, also
save some cost of redundnat llvm::sort.

Though clangd's index doesn't return duplications, our internal index
kythe will.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71300

Move 2 intrinsic class definitions so that they're all clustered in
one place.

Patch submitted to test commit access.

[PowerPC] [CodeGen] Use MachineBranchProbabilityInfo in EarlyIfPredicator to avoid the potential bug

Summary:
In the function `EarlyIfPredicator::shouldConvertIf()`, we call
`TII->isProfitableToIfCvt()` with `BranchProbability::getUnknown()`, it may
cause the potential assertion error for those hook which use `BranchProbability`
in `isProfitableToIfCvt()`, for example `SystemZ`.
`SystemZ` use `Probability < BranchProbability(1, 8))` in the function
`SystemZInstrInfo::isProfitableToIfCvt()`, if we call this function with
`BranchProbability::getUnknown()`, it will cause assertion error.

This patch is to fix the potential bug.

Reviewed By: ThomasRaoux

Differential Revision: https://reviews.llvm.org/D71273

This iterator range just includes physical registers and register masks,
which are interesting when dealing with register liveness.

Reviewers: evandro, t.p.northover, paquette, MatzeB, arsenm

Reviewed By: paquette

Differential Revision: https://reviews.llvm.org/D70562

It is discussed here https://reviews.llvm.org/D71118#inline-643172

Currently when a version is empty, llvm-readelf prints:
"000:   0 (*local*)       2 (<corrupt>)"

But GNU readelf does not treat empty section as corrupt.
There is no sense in having empty versions anyways it seems, but
this change is for consistency with GNU.

Differential revision: https://reviews.llvm.org/D71243

    The -fsplit-dwarf-inlining option does not conform to DWARF5 standard.
It creates children for Skeleton compilation unit. We need default behavior
to be DWARF5 compatible. Thus set default state for -fsplit-dwarf-inlining
into "false".

Differential Revision: https://reviews.llvm.org/D71304

Summary: Null type pointers could be dereferenced in some cases.

Reviewers: kadircet, sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71329

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71277

ARMWinEHPrinter was already designed to handle linked PE images
(since d2941b43), but resolving symbols didn't consistently
take the image base into account (as linked images seldom have a
symbol table, except for in MinGW setups).

Win64EHDumper wasn't really designed to handle linked images (it would
crash if executed on such a file), but a few concepts (getSymbol,
taking a virtual address instead of a relocation, and
getSectionContaining for finding the section containing a certain
virtual address) can be borrowed from ARMWinEHPrinter.

Adjust ARMWinEHPrinter to print the address of the exception handler
routine as a VA instead of an RVA, consistently with other addresses
in the same printout, and make Win64EHDumper print addresses similarly
for image cases.

Differential Revision: https://reviews.llvm.org/D71303

PowerPC has instruction to do the semantics of this piece of code:

vector int foo(vector int m, vector int n) {
  return (m + n + 1) >> 1;
}
This patch is adding the match rule to select it.

Differential Revision: https://reviews.llvm.org/D71002

I think this is no longer needed. The system should take care
of legalizing any new nodes that are added. I think this might
have been needed prior to r371709 or r307053.

Address post-commit review for D71163.

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D71326

MmapOrDie allocates memory multiple to page size. LowLevelAllocator
should use all that memory for the internal buffer because there are
chances that subsequent requests may be small enough to fit in that
space.

Differential Revision: https://reviews.llvm.org/D71275

arguments by value.

inaccessible comparison function.

of depending on it being set in the environment.  Fred's change
from October assumed that SDKROOT was set in the environment
so that 'xcrun --show-sdk-path' would print the path.  If it
was passed in as a Makefile variable, it wouldn't be set in
the environment and xcrun --show-sdk-path would always show the
macOS SDK path.  When running the lldb testsuite against an ios
device via lit, this seems to be the case.

Revert "[DebugInfo] Refactored macro related generation, added a test case for macinfo.dwo emission."

This reverts commit 307f60a1.

DebugInfo/X86/debug-macinfo-split-dwarf.ll fails on Windows:

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "c:\src\llvm-project\out\gn\bin\llc.exe" "-mtriple=x86_64-pc-windows-gnu" "-O0" "-split-dwarf-file=foo.dwo" "-filetype=obj"
Assertion failed: Section && "Cannot switch to a null section!", file ../../llvm/lib/MC/MCStreamer.cpp, line 1103
Stack dump:
0.	Program arguments: c:\src\llvm-project\out\gn\bin\llc.exe -mtriple=x86_64-pc-windows-gnu -O0 -split-dwarf-file=foo.dwo -filetype=obj

classification.

We were accidentally treating invalid scope specs as being empty,
resulting in our trying to form an ADL-only call with a qualified
callee, which tripped up an assert later on.

If llvm-ar is installed at arm-pokymllib32-linux-gnueabi-llvm-ar, it may
think it is llvm-lib due to the "lib" substring.

Improve the heuristic to make all the following work as intended:

llvm-ar-9 (llvm-9 package on Debian)
llvm-ranlib.exe
Lib.exe (reported by D44808)
arm-pokymllib32-linux-gnueabi-llvm-ar (reported by D71030)

Reviewed By: raj.khem, rupprecht

Differential Revision: https://reviews.llvm.org/D71302

[X86] Split v64i1 arguments into 2 v32i1s that will be promoted to v32i8 under min-legal-vector-width=256

This is an improvement to 88dacbd4

Summary:
Relands https://reviews.llvm.org/D70815.

The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to
`STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively
disabled the linking step in CMake checks.

This broke some builds (see 938c70b8).

Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to
STATIC_LIBRARY only when checking for presence of the `-funwind-tables`
flag, and then set it back to the original value so it doesn't affect
other checks.

Reviewers: mstorsjo, jfb

Subscribers: mgorny, christof, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D71117

For each defaulted operator<=> in a class that doesn't explicitly
declare any operator==, also inject a matching implicit defaulted
operator==.

Now, flags will result in differing hashes for a given MI. In effect, if
you have two instructions with everything identical except for their
flags then you should get two different hashes and fewer collisions.

Differential Revision: https://reviews.llvm.org/D70479

It was a step in the right direction but it is not clear how can this
fit into the checker API at this point. The pre-escape happens in the
analyzer core and the checker has no control over it. If the checker
is not interestd in a pre-escape it would need to do additional work
on each escape to check if the escaped symbol is originated from an
"uninteresting" pre-escaped memory region. In order to keep the
checker API simple we abandoned this solution for now.

We will reland this once we have a better answer for what to do on the
checker side.

This reverts commit f3a28202.

Summary: This is a follow up of D69281, it enables the X86 backend support for the FP comparision.

Reviewers: uweigand, kpn, craig.topper, RKSimon, cameron.mcinally, andrew.w.kaylor

Subscribers: hiraditya, llvm-commits, annita.zhang, LuoYuanke, LiuChen3

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70582

Otherwise, weak symbols leak into user programs when using `async` with
non-internal types.

Analogous to https://reviews.llvm.org/D71233 it is not safe to cache
something that depends on the actual ValueObject in a cache then keys
only off the type name.

Differential Revision: https://reviews.llvm.org/D71297

Differential Revision: https://reviews.llvm.org/D71296

This reverts commit f2ba9397, it was
causing build timeouts on sanitizer-x86_64-linux-autoconf such as
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/44917

This refactoring makes the lookup caching easier to reason about. This
has no observable effect although it does slightly change what is
being cached.

- Before this patch a negative lookup in the LanguageCategory would be
  cached, but a positive wouldn't.

- After this patch LanguageCategory lookups aren't cached by
  FormatManager, period. (LanguageCategory has its own FormatCache for this!)

Differential Revision: https://reviews.llvm.org/D71289

The cache in FormatCache uses only a type name as key. The hardcoded
formats, synthetic children, etc inspect an entire ValueObject to
determine their eligibility, which isn't modelled in the cache. This
leads to bugs such as the one in this patch (where two similarly named
types in different files have different hardcoded summary
providers). The problem is exaggerated in the Swift language plugin
due to the language's dynamic nature.

rdar://problem/57756763

Differential Revision: https://reviews.llvm.org/D71233

Summary:
The __name__ attribute is the correct way to get a function name in
Python 3. This also works with Python 2.

Reviewers: jroelofs, EricWF

Subscribers: christof, ldionne, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D71136

Suggested by Adrian.

[X86] Go back to considering v64i1 as a legal type under min-legal-vector-width=256. Scalarize v64i1 arguments and shuffles under min-legal-vector-width=256.

This reverts 3e1aee2b in favor
of a different approach.

Scalarizing isn't great codegen, but making the type illegal was
interfering with k constraint in inline assembly.

On multiple retry this issue won't duplicate - will revisit with author if
duplication works again.

This reverts commit c9e0b354.