[ELF] Allow mixed SHF_LINK_ORDER & non-SHF_LINK_ORDER sections and sort within InputSectionDescription

LLD currently does not allow non-contiguous SHF_LINK_ORDER components in an
output section. This makes it infeasible to add SHF_LINK_ORDER to an existing
metadata section if backward compatibility with older object files are
concerned.

We did not allow mixed components (like GNU ld) and D77007 relaxed to allow
non-contiguous SHF_LINK_ORDER components. This patch allows arbitrary mix, with
sorting performed within an InputSectionDescription. For example,
`.rodata : {*(.rodata.foo) *(.rodata.bar)}`, has two InputSectionDescription's.
If there is at least one SHF_LINK_ORDER and at least one non-SHF_LINK_ORDER in
.rodata.foo, they are ordered within `*(.rodata.foo)`: we arbitrarily place
SHF_LINK_ORDER components before non-SHF_LINK_ORDER components (like Solaris ld).

`*(.rodata.bar)` is ordered similarly, but the two InputSectionDescription's
don't interact.  It can be argued that this is more reasonable than the previous
behavior where written order was not respected.

It would be nice if the two different semantics (ordering requirement & garbage
collection) were not overloaded on one section flag, however, it is probably
difficult to obtain a generic flag at this point
(https://groups.google.com/forum/#!topic/generic-abi/hgx_m1aXqUo
"SHF_LINK_ORDER's original semantics make upgrade difficult").

(Actually, without the GC semantics, SHF_LINK_ORDER would still have the
sh_link!=0 & sh_link=0 issue. It is just that people find the GC semantics more
useful and tend to use the feature more often.)

GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=16833

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

While the instrumentation never calls dfsan_union in fast16labels mode,
the custom wrappers do.  We detect fast16labels mode by checking whether
any labels have been created.  If not, we must be using fast16labels
mode.

Reviewed By: vitalybuka

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

Use the TableGen directive back-end to generate code for the clauses unparsing.

Reviewed By: sscalpone, kiranchandramohan

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

... if the collected file doesn't exists.

This fixes the situation where LLDB can't create a file when capturing a
reproducer because the parent path doesn't exist, but can during replay
because the file collector created the directory hierarchy even though
the file doesn't exist.

This is covered by the lldb reproducer test suite.

The artifact combiner searches for the uses of G_MERGE_VALUES for
unmerge/trunc that need further combining. This also needs to handle
the vector merge opcodes the same way. This fixes leaving behind some
pairs I expected to be removed, that were if the legalizer is run a
second time.

The tests for it were missing so I've added them.

Reviewed By: #libc, EricWF

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

isWriteAtEndOfFunction needs to check all memory uses of Def, which is
much more expensive than getting the underlying objects in practice.
Switch the call order, as recommended by the TODO, which was added as
per an earlier review.

This shaves off a bit of compile-time.

This tests the driver, which is bypassed by the reproducer during
replay.

Add the missing LLDB_REGISTER_STATIC_METHOD macro and format the file.

Pin the test to use -enable-npm-optnone.
Before, optnone wasn't implemented under NPM, so the LPM and NPM runs produced different IR. Now with -enable-npm-optnone, that is no longer necessary.

Reviewed By: ychen

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

This fails due to the clang invocation running at -O0, producing an optnone function.
Then even with -O2 in the later invocations, LoopVectorizePass doesn't run on the optnone function.
So split this into an -O0 run and an -O2 run.

Reviewed By: asbirlea

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

Rename the existing expectedFailure to expectedFailureIfFn to better
describe its purpose and provide an overload for
unittest2.expectedFailure in decorators.py.

This reverts commit 7f84f62e.

Seems to be causing a bunch of compiler-rt test failures on
ppc64-linux bots.

Since -[no-]toc-optimize has not ever been used, we can enforce the two-dash form as well.

Currently the code does not account for the fact that getDomMemoryDef
can be called with ScanLimit == 0, if we reached the limit while
processing an earlier access. Also tighten the check a bit more and bump
the scan limit now that it is handled properly.

In some cases, this brings a 2x speedup in terms of compile-time.

* Also raises an exception on parse error.
* Removes placeholder smoketest.
* Adds docstrings.

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

Reviewed By: fhahn

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

Fixes multi-process-driver.cpp:221:19: error: use of undeclared
identifier 'SIG_IGN'

Only link against Python3_LIBRARY when LLDB_ENABLE_PYTHON is true. We
have to be more strict now becuase Python3_LIBRARY might be set to
NOTFOUND instead of being not set at all.

We may have an SGPR->VGPR copy if a totally uniform pointer
calculation is used for a VGPR pointer operand.

Also hack around a bug in MUBUF matching which would incorrectly use
MUBUF for global when flat was requested. This should really be a
predicate on the parent pattern, but the DAG always checked this
manually inside the complex pattern.

This sets some config parameters so we can run the asan tests with
llvm-lit,
e.g. `./bin/llvm-lit [...]/compiler-rt/test/asan`

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

The comment says that TestMultipleDebuggers was XFAILed because it was
failing nondeterministically in which case it should be skipped not
failed (as XPASS will cause the test suite to fail).

The reason it fails is because it was not marked as a no-debug-info test
case. I've ran the test in a loop and it has been passing consistently.
Let's enable it and see if the bots agree, if not we can skip it.

Run clang-format on all the c++ file of this project.

This function is available on llvm::Type and has been used by some clients of
the LLVM dialect before the transition. Implement the MLIR counterpart.

Reviewed By: schweitz

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

- Add variants of getAnalysis() and friends that operate on a specific derived
  operation types.
- Add OpPassManager::getAnalysis() to always call the base getAnalysis() with OpT.
- With this, an OperationPass can call getAnalysis<> using an analysis type that
  is generic (works on Operation *) or specific to the OpT for the pass. Anything
  else will fail to compile.
- Extend AnalysisManager unit test to test this, and add a new PassManager unit
  test to test this functionality in the context of an OperationPass.

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

This patch is a big sed to rename the following variables:

  s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
  s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
  s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
  s/PYTHON_RPATH/Python3_RPATH/g

I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.

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

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

If the same stream object is used for multiple compiles, the PAL metadata from eariler compilations will leak into later one.  See https://github.com/GPUOpen-Drivers/llpc/issues/882 for how this is happening in LLPC.

No tests were added because multiple compiles will have to happen using the same pass manager, and I do not see a setup for that on the LLVM side.  Let me know if there is a good way to test this.

Reviewed By: nhaehnle

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

This patch implements the handling for the R_PPC64_PCREL_OPT relocation as well
as the GOT relocation for the associated R_PPC64_GOT_PCREL34 relocation.

On Power10 targets with PC-Relative addressing, the linker can relax
GOT-relative accesses to PC-Relative under some conditions. Since the sequence
consists of a prefixed load, followed by a non-prefixed access (load or store),
the linker needs to replace the first instruction (as the replacement
instruction will be prefixed). The compiler communicates to the linker that
this optimization is safe by placing the two aforementioned relocations on the
GOT load (of the address).
The linker then does two things:

- Convert the load from the got into a PC-Relative add to compute the address
  relative to the PC
- Find the instruction referred to by the second relocation (R_PPC64_PCREL_OPT)
  and replace the first with the PC-Relative version of it

It is important to synchronize the mapping from legacy memory instructions to
their PC-Relative form. Hence, this patch adds a file to be included by both
the compiler and the linker so they're always in agreement.

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

So that the configuration box does not make a part of the plot invisible.

Reviewers: sivachandra

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

Thunk alignment is added in thie patch when using pc-rel instructions
to avoid crossing the 64 byte boundary.

Patched by: nemanjai, NeHuang
Reviewed By: sfertile, MaskRay

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

As with use-associated symbols, copy the attributes and flags from the
original symbol onto host-associated symbols when they are created.

This was showing up as an error on a deallocate of a host-associated
name. We reported an error because the symbol didn't have the POINTER
or ALLOCATABLE attribute.

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

CMake log:
```
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:823 (add_executable):
  Target "clangd" links to target "Threads::Threads" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
Call Stack (most recent call first):
  D:/llvm-project/clang/cmake/modules/AddClang.cmake:150 (add_llvm_executable)
  D:/llvm-project/clang/cmake/modules/AddClang.cmake:160 (add_clang_executable)
  D:/llvm-project/clang-tools-extra/clangd/tool/CMakeLists.txt:4 (add_clang_tool)

CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:821 (add_executable):
  Target "ClangdTests" links to target "Threads::Threads" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:1417 (add_llvm_executable)
  D:/llvm-project/clang-tools-extra/clangd/unittests/CMakeLists.txt:32 (add_unittest)

CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
  Target "RemoteIndexProtos" links to target "Threads::Threads" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
  D:/llvm-project/llvm/cmake/modules/FindGRPC.cmake:105 (add_clang_library)
  D:/llvm-project/clang-tools-extra/clangd/index/remote/CMakeLists.txt:2 (generate_grpc_protos)

CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
  Target "clangdRemoteIndex" links to target "Threads::Threads" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
  D:/llvm-project/clang-tools-extra/clangd/index/remote/CMakeLists.txt:11 (add_clang_library)

CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
  Target "clangdRemoteMarshalling" links to target "Threads::Threads" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
  D:/llvm-project/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt:1 (add_clang_library)

CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:823 (add_executable):
  Target "clangd-index-server" links to target "Threads::Threads" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
```

Reviewed By: kbobyrev

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

This should use the default mapping and insert a copy to the vcc bank,
and not try to insert a readfirstlane.