Currently LLDB uses epydoc to generate the Python API reference for the website.
epydoc however is unmaintained since more than a decade and no longer works with
Python 3. Also whatever setup we had once for generating the documentation on
the website server no longer seems to work, so the current website documentation
has been stale since more than a year.

This patch replaces epydoc with sphinx and its automodapi plugin that can
generate Python API references. LLVM already uses sphinx for the rest of the
documentation, so this way we are more consistent with the rest of LLVM. The
only new dependency is the automodapi plugin for sphinx.

This patch effectively does the following things:
* Remove the epydoc code.
* Make a new dummy Python API page in our website that just calls the Sphinx
  command for generated the API documentation.
* Add a mock _lldb module that is only used when generating the Python API.
 This way we don't have to build all of LLDB to generate the API reference.

Some notes:
* The long list of skips is necessary due to boilerplate functions that SWIG
  is generating. Sadly automodapi is not really scriptable from what I can see,
  so we have to blacklist this stuff manually.
* The .gitignore change because automodapi wants a subfolder of our
  documentation directory to place generated documentation files there. The path
  is also what is used on the website, so we can't really workaround this
  (without copying the whole `docs` dir somewhere else when we build).
* We have to use environment variables to pass our build path to our sphinx
  configuration. Sphinx doesn't support passing variables onto that script.

Reviewed By: JDevlieghere

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

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

It can be useful for an ObjectLinkingLayerCreator to allow callee errors to get propagated to the builder. Specifically, this is the case when the ObjectLayer uses the EHFrameRegistrationPlugin, because it requires a TPCEHFrameRegistrar and instantiation for it may fail (e.g. if the required registration symbols are missing in the target process).

Reviewed By: lhames

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

All other layers in LLJIT are stored as unique_ptr's already. At this point, it is not strictly necessary for ObjTransformLayer, but it makes a follow-up change more straightforward.

Reviewed By: lhames

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

In order to limit the number of combinations of REINTERPRET_CAST,
whilst at the same time prevent overlap with BITCAST, this patch
establishes the following rules:

1. The operand and result element types must be the same.
2. The operand and/or result type must be an unpacked type.

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

I noticed in D94450 that there were quite a few places where we generate
the sequence:
```
  xN <- comparison ...
  xN <- xor xN, 1
  bnez xN, symbol
```

Given we know the XOR will be used by BRCOND, which only looks at the lowest
bit, I think we can remove the XOR and just invert the branch condition in
these cases?

The case mostly seems to come up in floating point tests, where there is often
more logic to combine the results of multiple SETCCs, rather than a single
(BRCOND (SETCC ...) ...).

Reviewed By: craig.topper

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

This patch pull offset calculation logic out of DynamicRegisterInfo::Finalize
into a separate function. We are going to call this function whenever we
update SVE register sizes.

Reviewed By: labath

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

In gdb-remote process we have register infos defind as a refernce object of
GDBRemoteDynamicRegisterInfo class. In past register infos have remained
constant througout the life time of a process.

This has changed after AArch64 SVE support where register infos will have
per-thread configuration. SVE registers will have per-thread size and can
be updated while running. This patch aims to build up for that support by
changing GDBRemoteDynamicRegisterInfo reference to a shared pointer deinfed
per-thread.

Reviewed By: labath

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

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

This removes excessive YAML keys from `SHT_GNU_verdef` sections.
Those keys are set by default.

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

This patch:
1) Makes `Version`, `Flags`, `VersionNdx` and `Hash` fields to be `Optional<>`.
2) Disallows dumping version definitions that have `vd_version != 1`.
   `vd_version` identifies the version of the structure itself.
   (https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/symversion.html,
    https://docs.oracle.com/cd/E19683-01/816-7777/chapter6-80869/index.html)
3) Stops dumping default values for `Version`, `Flags`, `VersionNdx` and `Hash` fields.
4) Refines testing.

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

For the ARM hard-float calling convention, calls to variadic functions
need to be treated diffrently, even if only the fixed arguments are
provided.

This fixes GCC-C-execute-pr68390 in the test-suite, which is failing on
the ARM GlobaISel bot.

It is possible to simplify the logic that extracts symbol names.

D94667 made the `NMSymbol::Name` to be `std::string`,
what allowed this simplification.

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

 - Adds LLVM_LIBC_IS_DEFINED macro to libc/src/__support/common.h
 - Adds a few knobs to memcpy to help with experimentations:
   - LLVM_LIBC_MEMCPY_X86_USE_ONLY_REPMOVSB replaces the implementation with a single call to rep;movsb
   - LLVM_LIBC_MEMCPY_X86_USE_REPMOVSB_FROM_SIZE customizes where the usage of rep;movsb

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

`dumpSymbolNamesFromObject` is the method that dumps symbol names.

It has 563 lines, mostly because of huge piece of MachO specific code.
In this patch I move it to separate helper method.

The new size of `dumpSymbolNamesFromObject` is 93 lines. With it it becomes
much easier to maintain it.

I had to change the type of 2 name fields to `std::string`, because MachO logic
uses temporarily buffer strings (e.g `ExportsNameBuffer`, `BindsNameBuffer` etc):

```
  std::string ExportsNameBuffer;
  raw_string_ostream EOS(ExportsNameBuffer);
```

these buffers were moved to `dumpSymbolsFromDLInfoMachO` by this patch and
invalidated after return. Technically, before this patch we had a situation
when local pointers (symbol names) were assigned to members of global static `SymbolList`,
what is dirty by itself.

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

New dwarf operator DW_OP_LLVM_implicit_pointer is introduced (present only in LLVM IR)
This operator is required as it is different than DWARF operator
DW_OP_implicit_pointer in representation and specification (number
and types of operands) and later can not be used as multiple level.

Reviewed By: aprantl

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

If mutex::try_lock() is called in a thread that already owns the mutex,
the behavior is undefined. The patch fixes the issue by creating another
thread, where the call is allowed.

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

[AArch64][GlobalISel] Fix fallbacks introduced for G_SITOFP in 8f283caf

If we have an integer->fp convert that has differing sizes, e.g. s32 to s64,
then don't try to convert it to AArch64::G_SITOF since it won't select.

This addressed post commit comments for D93900.

GCC had an issue and requires placing a specialization of
`printUnwindInfo` to a namespace to compile:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480

Under -mabi=ieeelongdouble on PowerPC, IEEE-quad floating point semantic
is used for long double. This patch mutates call to related builtins
into f128 version on PowerPC. And in theory, this should be applied to
other targets when their backend supports IEEE 128-bit style libcalls.

GCC already has these mutations except nansl, which is not available on
PowerPC along with other variants (nans, nansf).

Reviewed By: RKSimon, nemanjai

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

Revert "Reapply "ADT: Fix reference invalidation in SmallVector::push_back and single-element insert""

This reverts commit 260a856c.
This reverts commit 3043e5a5.
This reverts commit 49142991.

This change had a larger than anticipated compile-time impact,
possibly because the small value optimization is not working as
intended. See D93779.

This patch adds support to wasm-ld for linking multiple table references
together, in a manner similar to wasm globals. The indirect function
table is synthesized as needed.

To manage the transitional period in which the compiler doesn't yet
produce TABLE_NUMBER relocations and doesn't residualize table symbols,
the linker will detect object files which have table imports or
definitions, but no table symbols. In that case it will synthesize
symbols for the defined and imported tables.

As a change, relocatable objects are now written with table symbols,
which can cause symbol renumbering in some of the tests. If no object
file requires an indirect function table, none will be written to the
file. Note that for legacy ObjFile inputs, this test is conservative: as
we don't have relocs for each use of the indirecy function table, we
just assume that any incoming indirect function table should be
propagated to the output.

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

Basic support of A64FX was added in D75594 but its scheduling model
was missing. This commit adds the scheduling model. Also, this commit
amends/adds some subtarget parameters of A64FX.

The A64FX Microarchitecture Manual, which is source information of
this commit, is on GitHub.

https://github.com/fujitsu/A64FX/

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

It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).

We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.

Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.

Reviewed By: Bigcheese

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

Instead of passing the whole `TargetOptions` and `FrontendOptions` to `ParseCodeGenArgs` give it only the necessary members.
This makes tracking the dependencies between various parsers and option groups easier.

Reviewed By: Bigcheese

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

Instead of passing the whole `TargetOptions` and `PreprocessorOptions` to `ParseLangArgs` give it only the necessary members.
This makes tracking the dependencies between various parsers and option groups easier.

Reviewed By: Bigcheese

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

This is a very minor improvement during iteration graph construction.
If the first attempt considering the dimension order of all tensors fails,
a second attempt is made using the constraints of sparse tensors only.
Dense tensors prefer dimension order (locality) but provide random access
if needed, enabling the compilation of more sparse kernels.

Reviewed By: penpornk

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

Add Semantic check for Flang OpenMP 4.5 - 2.7.1  Do Loop restrictions on single directive and firstprivate clause.

Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the 'do' iteration variable is a variable in 'Firstprivate' clause.

Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp

Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90

Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval

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

Identified with readability-redundant-control-flow.

Use `memcpy` rather than copying bytes one by one, for there might be large
size structs to move.

Reviewed By: gchatelet, sivachandra

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

In order to import patterns for these, we need to define new ops that can map to
the AArch64ISD::[SU]ITOF nodes. We then transform fpr->fpr variants of the generic
opcodes to these custom opcodes in preisel-lowering. We have to do it here and
not the PostLegalizer combiner because this has to run after regbankselect.

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

This patch changes the default range used to anchor the include insertion to use
an expansion loc.  This ensures that the location is valid, when the user relies
on the default range.

Driveby: extend a FIXME for a problem that was emphasized by this change; fix some spellings.

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

[libomptarget][nvptx] Reduce calls to cuda header

Remove use of clock_t in favour of a builtin. Drop a preprocessor branch.

Reviewed By: jdoerfert

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

This relands commit e0963ae2, which was
reverted on commit 82c4153e due to a
test failure, which turned out to be a false positive.

G_[US]ITOFP users of loads on AArch64 can operate on both gpr and fpr banks for scalars.
Because of this, if their source is a load, then that load can be assigned to an fpr
bank and therefore avoid having to do a cross bank copy via a gpr->fpr conversion.

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

When a use-associated procedure was included in a generic, we weren't
correctly recording that fact. The ultimate symbol was added rather than
the local symbol.

Also, improve the message emitted for the specific procedure by
mentioning the module it came from.

This fixes one of the problems in https://bugs.llvm.org/show_bug.cgi?id=48648.

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

[libomptarget][nvptx][nfc] Move target_impl functions out of header

This removes most of the differences between the two target_impl.h.

Also change name mangling from C to C++ for __kmpc_impl_*_lock.

Reviewed By: tianshilei1992

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

With the recent changes to linalg on tensor semantics, the tiling
operations works out-of-the-box for generic operations. Add a test to
verify that and some minor refactoring.

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