[lldb] Add more logging to __lldb_apple_objc_v2_get_dynamic_class_info

[AIX][TLS] Generate TLS variables in assembly files

This patch allows generating TLS variables in assembly files on AIX.
Initialized and external uninitialized variables are generated with the
.csect pseudo-op and local uninitialized variables are generated with
the .comm/.lcomm pseudo-ops. The patch also adds a check to
explicitly say that TLS is not yet supported on AIX.

Reviewed by: daltenty, jasonliu, lei, nemanjai, sfertile
Originally patched by: bsaleil
Commandeered by: NeHuang

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

[runtimes] Use standalone build only for compiler-rt

compiler-rt needs to use standalone build because of the assumptions
made by its build, but other runtimes can use non-standalone build.

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

[libc++] Add bind_front function (P0356R5).

Implementes [[ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0356r5.html | P0356R5 ]]. Adds `bind_front` to `functional`.

Reviewed By: ldionne, #libc, Quuxplusone

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

[lldb] Extend Python convenience variable table with equivalent APIs

Add a column to the table of convenience variables with the equivalent
API to get to the current debugger, target, process, etc.

We often get asked to make convenience variables available outside of
the interactive interpreter. After explaining why that's not possible, a
common complaint is that it's hard to find out how to get to these
variables in a non-interactive context, for example how to get to the
current frame when given a thread. This patch aims to alleviate that by
including the APIs to navigate between these instances in the table.

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

Migrate to llvm::unique_function instead of static member functions for callbacks

A few cleanups suggested in another patch review's comments:

1. Use llvm:unique_function for storing & invoking callbacks from
   Editline to IOHandler
2. Change return type of one of the callback setters from bool to void,
   since it's return value was never used
3. Moved the callback setters inline & made them nonstatic, since that's
   more consistent with other setter definitions
4. Removed the baton parameter since we no longer need it anymore

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

[opt] Error if -debug-pass is specified alongside the new PM

Reviewed By: ychen

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

[NFCI][VPlan] Modify Recipes' print methods to honor Indent parameter

Reviewed By: fhahn

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

[test] Fix CodeGen/VE/Scalar tests

[mlir][sparse] do not ignore ordering for "dense" tensor linked with sparse type

Reviewed By: bixia

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

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure.  Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure.  It's also possible to create
circular dependency chains of more than two procedures.

I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces.  I marked the associated symbols of such
procedures by calling SetError() on them.  When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.

With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure.  But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made.  This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.

I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function.  This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.

I also fixed the error message used when reporting recursively defined
dummy procedure arguments by removing extra apostrophes and sorting the
list of symbols.

I also added tests that will crash the compiler without this change.

Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ...  All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.

Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory.  But I was unable to create
a test that caused a problem.  Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems.  Symbols in enclosing or
parallel scopes can have the same name.  Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.

This patch supersedes D97749.

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

hack to unbreak check-llvm on win after https://reviews.llvm.org/D97335

fix attempt http://reviews.llvm.org/rGbbdb4c8c9bcef0e didn't work

The problem is that the test tries to look up
llvm_orc_registerJITLoaderGDBWrapper from the llvm-jitlink.exe
executable, but the symbol wasn't exported. Just manually export it
for now. There's a FIXME with a suggestion for a real fix.

[libunwind] [risc-v] This patch is for fixing
immediate build failure when Cross Unwinding enabled.
Follow up patch will cleanup some Macros handling.

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

[OpenMP] Add allocator support for target memory

This is a preview of allocator support for target memory that depends on the
offload runtime API which allocates memory as described below.

llvm_omp_target_alloc_host(size_t size, int device_num);
-- Returns non-migratable memory owned by host.
-- Memory is accessible by host and device(s).

llvm_omp_target_alloc_shared(size_t size, int device_num);
-- Returns migratable memory owned by host and device.
-- Memory is accessible by host and device.

llvm_omp_target_alloc_device(size_t size, int device_num);
-- Returns memory owned by device.
-- Memory is only accessible by device.

New memory space and predefined allocator names are
-- llvm_omp_target_host_mem_space
-- llvm_omp_target_shared_mem_space
-- llvm_omp_target_device_mem_space
-- llvm_omp_target_host_mem_alloc
-- llvm_omp_target_shared_mem_alloc
-- llvm_omp_target_device_mem_alloc

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

[libcxx] adds common_reference to <type_traits>

Implements part of P0898R3 Standard Library Concepts

Reworks D74351 to use requires-clauses over SFINAE and so that it more
closely follows the wording.

Co-authored by: Michael Schellenberger Costa <mschellenbergercosta@googlemail.com>

(Michael did all the heavy lifting and I came in to polish it for
 submission, since Michael is focussing on `std::format` now.)

Reviewed By: ldionne, #libc

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

GlobalISel: Merge and cleanup more AMDGPU call lowering code

This merges more AMDGPU ABI lowering code into the generic call
lowering. Start cleaning up by factoring away more of the pack/unpack
logic into the buildCopy{To|From}Parts functions. These could use more
improvement, and the SelectionDAG versions are significantly more
complex, and we'll eventually have to emulate all of those cases too.

This is mostly NFC, but does result in some minor instruction
reordering. It also removes some of the limitations with mismatched
sizes the old code had. However, similarly to the merge on the input,
this is forcing gfx6/gfx7 to use the gfx8+ ABI (which is what we
actually want, but SelectionDAG is stuck using the weird emergent
ABI).

This also changes the load/store size for stack passed EVTs for
AArch64, which makes it consistent with the DAG behavior.

Promote scalars to load addresses when dereferencing them.

This is a follow-up to 188b0747c1664d962e94f00b5e3caac529fa1e26. This
is a very narrow fix to a more general problem. LLDB should be better
at distinguishing between implict and memory location descriptions.

rdar://74902042

[AST] Remove unused Loop member (NFC)

To fix some build bots after D89264.

[clangd] Move DraftStore from ClangdLSPServer into ClangdServer.

ClangdServer already gets notified of every change, so it makes sense for it to
be the source of truth.
This is a step towards having ClangdServer expose a FS that includes dirty
buffers: D94554

Related changes:
 - version is now optional for ClangdServer, to preserve our existing fuzziness
   in this area (missing version ==> autoincrement)
 - ClangdServer::format{File,Range} are now more regular ClangdServer functions
   that don't need the code passed in. While here, combine into one function.
 - incremental content update logic is moved from DraftStore to
   ClangdLSPServer, with most of the implementation in SourceCode.cpp.
   DraftStore is now fairly trivial, and will probably ultimately be
   *replaced* by the dirty FS stuff.

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

[cte][NFC] Remove all references to stdlib stream headers.

Inclusion of iostream is frobidden and using other stream classes from standard library is discouraged as per https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden

Reviewed By: sammccall

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

[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add

Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment.

This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.

[WebAssembly] Fix more ExceptionInfo grouping bugs

This fixes two bugs in `WebAssemblyExceptionInfo` grouping, created by
D97247. These two bugs are not easy to split into two different CLs,
because tests that fail for one also tend to fail for the other.

- In D97247, when fixing `ExceptionInfo` grouping by taking out
  the unwind destination' exception from the unwind src's exception, we
  just iterated the BBs in the function order, but this was incorrect;
  this changes it to dominator tree preorder. Please refer to the
  comments in the code for the reason and an example.

- After this subexception-taking-out fix, there still can be remaining
  BBs we have to take out. When Exception B is taken out of Exception A
  (because EHPad B is the unwind destination of EHPad A), there can
  still be BBs within Exception A that are reachable from Exception B,
  which also should be taken out. Please refer to the comments in the
  code for more detailed explanation on why this can happen. To make
  this possible, this splits `WebAssemblyException::addBlock` into two
  parts: adding to a set and adding to a vector. We need to iterate on
  BBs within a `WebAssemblyException` to fix this, so we add BBs to sets
  first. But we add BBs to vectors later after we fix all incorrectness
  because deleting BBs from vectors is expensive. I considered removing
  the vector from `WebAssemblyException`, but it was not easy because
  this class has to maintain a similar interface with `MachineLoop` to
  be wrapped into a single interface `SortRegion`, which is used in
  CFGSort.

Other misc. drive-by fixes:
- Make `WebAssemblyExceptionInfo` do not even run when wasm EH is not
  used or the function doesn't have any EH pads, not to waste time
- Add `LLVM_DEBUG` lines for easy debugging
- Fix `preds` comments in cfg-stackify-eh.ll
- Fix `__cxa_throw`'s signature in cfg-stackify-eh.ll

Fixes https://github.com/emscripten-core/emscripten/issues/13554.

Reviewed By: dschuff, tlively

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

[clang-tidy] Simplify unused RAII check

Fix handling of default construction where the constructor has a default arg.

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

[LICM] Make promotion faster

Even when MemorySSA-based LICM is used, an AST is still populated
for scalar promotion. As the AST has quadratic complexity, a lot
of time is spent in this step despite the existing access count
limit. This patch optimizes the identification of promotable stores.

The idea here is pretty simple: We're only interested in must-alias
mod sets of loop invariant pointers. As such, only populate the AST
with loop-invariant loads and stores (anything else is definitely
not promotable) and then discard any sets which alias with any of
the remaining, definitely non-promotable accesses.

If we promoted something, check whether this has made some other
accesses loop invariant and thus possible promotion candidates.

This is much faster in practice, because we need to perform AA
queries for O(NumPromotable^2 + NumPromotable*NumNonPromotable)
instead of O(NumTotal^2), and NumPromotable tends to be small.
Additionally, promotable accesses have loop invariant pointers,
for which AA is cheaper.

This has a signicant positive compile-time impact. We save ~1.8%
geomean on CTMark at O3, with 6% on lencod in particular and 25%
on individual files.

Conceptually, this change is NFC, but may not be so in practice,
because the AST is only an approximation, and can produce
different results depending on the order in which accesses are
added. However, there is at least no impact on the number of promotions
(licm.NumPromoted) in test-suite O3 configuration with this change.

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

BPF: Fix a bug in peephole TRUNC elimination optimization

Andrei Matei reported a llvm11 core dump for his bpf program
   https://bugs.llvm.org/show_bug.cgi?id=48578
The core dump happens in LiveVariables analysis phase.
  #4 0x00007fce54356bb0 __restore_rt
  #5 0x00007fce4d51785e llvm::LiveVariables::HandleVirtRegUse(unsigned int,
      llvm::MachineBasicBlock*, llvm::MachineInstr&)
  #6 0x00007fce4d519abe llvm::LiveVariables::runOnInstr(llvm::MachineInstr&,
      llvm::SmallVectorImpl<unsigned int>&)
  #7 0x00007fce4d519ec6 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int)
  #8 0x00007fce4d51a4bf llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&)
The bug can be reproduced with llvm12 and latest trunk as well.

Futher analysis shows that there is a bug in BPF peephole
TRUNC elimination optimization, which tries to remove
unnecessary TRUNC operations (a <<= 32; a >>= 32).
Specifically, the compiler did wrong transformation for the
following patterns:
   %1 = LDW ...
   %2 = SLL_ri %1, 32
   %3 = SRL_ri %2, 32
   ... %3 ...
   %4 = SRA_ri %2, 32
   ... %4 ...

The current transformation did not check how many uses of %2
and did transformation like
   %1 = LDW ...
   ... %1 ...
   %4 = SRL_ri %2, 32
   ... %4 ...
and pseudo register %2 is used by not defined and
caused LiveVariables analysis core dump.

To fix the issue, when traversing back from SRL_ri to SLL_ri,
check to ensure SLL_ri has only one use. Otherwise, don't
do transformation.

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

Add __builtin_isnan(__fp16) testcase

Reviewed By: rjmccall

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

[lld-macho] Rework length check when opening input files

This reverts diff D97610 (commit 0223ab035c199e537a0040857ba147ced87fd533) and adds a one-line fix to verify that a `MemoryBufferRef` has sufficient length before reading a 4-byte magic number.

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

[AArch64][GlobalISel] Enable use of the optsize predicate in the selector.

To do this while supporting the existing functionality in SelectionDAG of using
PGO info, we add the ProfileSummaryInfo and LazyBlockFrequencyInfo analysis
dependencies to the instruction selector pass.

Then, use the predicate to generate constant pool loads for f32 materialization,
if we're targeting optsize/minsize.

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

[mlir][linalg] Only generate one var for an attrUse.

Some variables are unused after D97383 landed. We should generate one symbol for one attrUse.

Reviewed By: stellaraccident

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

[llvm-jitlink] Prevent missing symbols from JITLoaderGDB with MSVC mangling

The issue came up on builder clang-x64-windows-msvc after 5182a7901a5d83dfd15021d01e8a1899910130ec

[libcxx] [test] Pass some windows environment variables through to test processes

Normally, the run.py wrapper script runs the child processes in
a clean environment, with only the environment variables available
that are passed via the --env parameter.

However, the COMSPEC and TEMP variables are kind of necessary when
running some tests; COMSPEC is necessary for finding the interpreter
when executing commands via std::system().

Before f1a96de1bc8db527b5eb820c36c17e275900ca2b, tests were executed
via an intermediate shell which implicitly readded the COMSPEC variable.

The TEMP variable allows temp files to be placed in a sensible
location; if unset, they're placed in the default temp fallback of
C:\Windows instead.

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

[libcxx] Explicitly return the expected error code in create_directories if the parent isn't a directory

On windows, going ahead and actually trying to create the directory
doesn't return an error code that maps to
std::errc::not_a_directory in this case.

This fixes two cases of
    TEST_CHECK(ErrorIs(ec, std::errc::not_a_directory))
in filesystems/fs.op.funcs/fs.op.create_directories/create_directories.pass.cpp
for windows (in testcases added in 59c72a70121567f7aee347e96b4ac8f3cfe9f4b2).

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

[SDAG] allow partial undef vector constants with select->logic folds

This is an enhancement suggested in the original review/commit:
D97730 / 7fce3322a283

[AArch64] add select tests with partial vector undefs; NFC

Fix `debuginfo-tests/llvm-prettyprinters` build after MLIR API change in e6260ad043d8 (NFC)

[ARM] Use 0, not ZR during ISel for CSINC/INV/NEG

Instead of converting the 0 into a ZR reg during lowering, do that with
tablegen by matching the zero immediate. This when combined with other
optimizations is more likely to use ZR and helps keep the DAG more
easily optimizable. It should not otherwise effect code generation.

[SystemZ]  Assign the full space for promoted and split outgoing args.

When a large "irregular" (e.g. i96) integer call argument is converted to
indirect, 64-bit parts are stored to the stack. The full stack space
(e.g. i128) was not allocated prior to this patch, but rather just the exact
space of the original type. This caused neighboring values on the stack to be
overwritten.

Thanks to Josh Stone for reporting this.

Review: Ulrich Weigand
Fixes https://bugs.llvm.org/show_bug.cgi?id=49322
Differential Revision: https://reviews.llvm.org/D97514

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure.  Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure.  It's also possible to create
circular dependency chains of more than two procedures.

I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces.  I marked the associated symbols of such
procedures by calling SetError() on them.  When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.

With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure.  But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made.  This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.

I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function.  This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.

I also fixed the error message used when reporting recursively defined
dummy procedure arguments by removing extra apostrophes and sorting the
list of symbols.

I also added tests that will crash the compiler without this change.

Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ...  All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.

Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory.  But I was unable to create
a test that caused a problem.  Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems.  Symbols in enclosing or
parallel scopes can have the same name.  Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.

This patch supersedes D97749.

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

[gn build] fix llvm-jitlink tests on linux after ef2389235c5dec0

[AMDGPU] Make OMod explicit for V_CVT_{U,I}*

Make OMod explicit instead of implied by HasModifiers in the
operand list. Requires explicitly setting HasOMod=1 for
irregular OMod usage in instruction V_CVT_{U,I}*

Reviewed By: foad

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

Change-Id: I230e1476f529e816eec60e242531f23a99e3839f

[libcxx] [test] Fix a test error with condvars with trivial destruction

If the destructor is trivial (_LIBCPP_HAS_TRIVIAL_CONDVAR_DESTRUCTION,
the constructor always is), the compiler warns about the
std::condition_variable being unused.

Add a cast to void to silence the warning about the object being unused.

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

[flang][f18] Add missing line in help text (nfc)

[libc++] Add a utility script to run the Docker image used by builders

Several contributors have been asking me how to reproduce the CI
environment locally. This is the last step towards making that work
out-of-the-box. Basically, just run `libcxx/utils/ci/run-buildbot-container`
and you're good to go.

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

[clang+lld] Pass -platform_version args to ld64.lld

Fix regression where we aren't passing `-platform_version` to new ld64.lld after {D95204}.

Most of the changes were originally in D95204, but I backed them out due to
test failures on builds which have `CLANG_DEFAULT_LINKER=lld`. The tests are
properly updated in this diff.

Reviewed By: #lld-macho, thakis

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

[flang][driver] Fix -fdefault* family bug

This patch provides a fix for the `fdefault-*` family in f18

(Please consult `D96344` for details)

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

[lld-macho] Change loadReexport to handle the case where a TAPI re-exports to reference documents nested within other TBD.

Currently, it was delibrately impleneted to not handle this case, but as it has turnt out, we need this feature.
The concrete use case is
       `System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa` reexports
               /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit , which then rexports
                    /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation

The current implemention uses a global currentTopLevelTapi, which is not reset until it finishes loading the whole tree.
This is a problem because if the top-level is set to Cocoa, then when we get to UIFoundation, it will try to find UIFoundation in the current top level, which is Cocoa and will not find it.

The right thing should be:
 - When loading a library from a TBD file, re-exports need to be looked up in the auxiliary documents within the same TBD.
 - When loading from an actual dylib, no additional TBD documents need to be examined.
 - In no case does a re-export mentioned in one TBD file need to be looked up in a document in an auxiliary document from a different TBD file

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

[TableGen] Add IntrNoMerge as intrinsic property

There is a function attribute 'nomerge' in addition to 'noduplicate'
and 'convergent'. Both 'noduplicate' and 'convergent' have corresponding
intrinsic properties. This patch adds an intrinsic property for the
'nomerge' attribute.

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

Revert "Revert "[clangd] Use ML Code completion ranking as default.""

The ASAN failure was fixed by
https://github.com/llvm/llvm-project/commit/bf935a034b345e905907c80030c67ef8f737d56a.

This reverts commit 7f086d74c347750c1da619058eb5b3e79c2fae14.

[RISCV] Support fixed-length INSERT_VECTOR_ELT

This patch enables support for lowering INSERT_VECTOR_ELT on
fixed-length vector types. The strategy follows that for scalable vector
types.

This patch also includes a quick fix to prevent the compiler infinitely
looping between lowering BUILD_VECTOR as VECTOR_SHUFFLE and back again.

Reviewed By: craig.topper

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

[clangd] Include macro expansions in documentSymbol hierarchy

Browsing macro-generated symbols is confusing.
On the one hand, it seems very *useful* to be able to see the summary of
symbols that were generated.
On the other hand, some macros spew a lot of confusing symbols into the
namespace and when used repeatedly (ABSL_FLAG) can create a lot of spam
that's hard to navigate.

Design constraints:
 - the macro expansion tree need not align with the AST, though it often
   does in practice.
   We address this by defining the nesting based on the *primary*
   location of decls, rather than their ranges.
 - DocumentSymbol.children[*].range should nest within DocumentSymbol.range
   (This constraint is not in LSP "breadcrumbs" breaks without it)
   We adjust macro ranges so they cover their "children", rather than
   just the macro expansion
 - LSP does not have a "macro expansion" symbolkind, nor does it allow a
   symbol to have no kind. I've arbitrarily picked "null" as this is
   unlikely to conflict with anything useful.

This patch makes all macros and children visible for simplicity+consistency,
though in some cases it may be better to elide the macro node.
We may consider adding heuristics for this in future (e.g. when it expands
to one decl only?) but it doesn't seem clear-cut to me.

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

[Instcombine][NFC]Simplify logical reductions tests, NFC.

[AA] Cache (optionally) estimated PartialAlias offsets.

For the cases of two clobbering loads and one loaded object is fully contained
in the second `BasicAAResult::aliasGEP` returns just `PartialAlias` that
is actually more common case of partial overlap, it doesn't say anything about
actual overlapping sizes.

AA users such as GVN and DSE have no functionality to estimate aliasing of GEPs
with non-constant offsets. The change stores estimated relative offsets so they
can be used further.

Reviewed By: nikic

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

Stop traping on sNaN in __builtin_isinf

__builtin_isinf currently generates a floating-point compare operation
which triggers a trap when faced with a signaling NaN in StrictFP mode.
This commit uses integer operations instead to not generate any trap in
such a case.

Reviewed By: mibintc

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

Test Commmit

[nfc] [lldb] DWARFDebugInfoEntry::Extract(): reindent

[lldb] DWARFDebugInfoEntry::Extract(): Print an error for unsupported DW_FORM_*

[clangd] Show hex value of numeric constants

Don't show negative numbers
Don't show numbers <10 (hex is the same as decimal)
Show numeric enum values in hex too

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

[gn build] (manually) port 99a6d003edbe

[gn build] Port f47ff8cff1ed

[gn build] Port ef2389235c5d

[clangd] Make categorical features 64 bit in DecisionForest Model.

CodeCompletionContext::Kind has 36 Kinds. The completion model used to
support categorical features of 32 cardinality.
Due to this clangd tests were failing asan tests due to overflow.

This patch makes the completion model support 64 cardinality of
categorical features by storing ENUM Features as uint64_t instead of
uint32_t.

Verified that this fixes the asan failures.

Latency: 6.7ms (old) VS 6.8ms (new) per 1000 predictions.

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

[OPENMP50]Mapping of the subcomponents with the 'default' mappers.

If the mapped structure has data members, which have 'default' mappers,
need to map these members individually using their 'default' mappers.

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

AArch64: report fp16 arithmetic is present for apple-a11 CPU.

AArch64.td got it right, but the target-parser dropped it, leading to missing
feature flags in Clang.

[clang] DeltaTree::AddDelta - fix "initialization is never read" clang-tidy warning. NFCI.

[DSE] eliminateDeadStoresMemorySSA - fix "initialization is never read" clang-tidy warning. NFCI.

Revert "[flang] Detect circularly defined interfaces of procedures"

This reverts commit 93c5e6bb49ca502d266700dd292e3873dfa51bb6.

This patch updates resolve102.f90 which is now failing in 6 out 8 of our
public buildbots:
  * http://lab.llvm.org:8011/#/builders/21/builds/9625
  * http://lab.llvm.org:8011/#/builders/134/builds/2395
  * http://lab.llvm.org:8011/#/builders/79/builds/6298
  * http://lab.llvm.org:8011/#/builders/66/builds/2084
  * http://lab.llvm.org:8011/#/builders/135/builds/2485
  * http://lab.llvm.org:8011/#/builders/32/builds/3551

Please see the following revisions for more context:
  * https://reviews.llvm.org/D97201
  * https://reviews.llvm.org/D97749

[clangd] findExplicitReferences impl filters nulls centrally. NFC

[SLP]Merge reorder and reuse shuffles.

It is possible to merge reuse and reorder shuffles and reduce the total
cost of the vectorization tree/number of final instructions.

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

[Orc] Fix MSVC error: conversion from 'initializer list' requires a narrowing

Split `ElementwiseMappable` trait into four more precise traits.

Some elementwise operations are not scalarizable, vectorizable, or tensorizable.
Split `ElementwiseMappable` trait into the following, more precise traits.
  - `Elementwise`
  - `Scalarizable`
  - `Vectorizable`
  - `Tensorizable`
This allows for reuse of `Elementwise` in dialects like HLO.

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

[SDAG] allow vector types for select->logic folds

This prepares codegen for a change that will remove the identical
folds from IR because they are not poison-safe. See
D93065 / D97360
for details.

We already generically support scalar types, and there are various
target-specific transforms that overlap the vector folds. For example,
x86 recognizes the and patterns, but not or. We can end up with 1
extra instruction there, but I think that is still preferred over the
blendv alternative that loads a constant vector.

If this is not optimal, then it should be fixed with a later transform
(this change is not expected to result in any regressions because
InstCombine currently does the same thing).

Removing custom code and supporting undefs in constant-pattern-matching
can be follow-up changes.

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

[lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

LLDB has been failing on binaries produced by new GCC 11.0 with -gdwarf-5.

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

[Orc] Fix remaining memory size of slab allocator

[docs][JITLink] Fix a typo (NFC)

[Orc] Extend lli debug support tests to JITLink

[lli] Add JITLink in-process debug support

lli aims to provide both, RuntimeDyld and JITLink, as the dynamic linkers/loaders for it's JIT implementations. And they both offer debugging via the GDB JIT interface, which builds on the two well-known symbol names `__jit_debug_descriptor` and `__jit_debug_register_code`. As these symbols must be unique accross the linked executable, we can only define them in one of the libraries and make the other depend on it. OrcTargetProcess is a minimal stub for embedding a JIT client in remote executors. For the moment it seems reasonable to have the definition there and let ExecutionEngine depend on it, until we find a better solution.

This is the second commit for the reviewed patch.

Reviewed By: lhames

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

[Orc] Add JITLink debug support plugin for ELF x86-64

Add a new ObjectLinkingLayer plugin `DebugObjectManagerPlugin` and infrastructure to handle creation of `DebugObject`s as well as their registration in OrcTargetProcess. The current implementation only covers ELF on x86-64, but the infrastructure is not limited to that.

The journey starts with a new `LinkGraph` / `JITLinkContext` pair being created for a `MaterializationResponsibility` in ORC's `ObjectLinkingLayer`. It sends a `notifyMaterializing()` notification, which is forwarded to all registered plugins. The `DebugObjectManagerPlugin` aims to create a  `DebugObject` form the provided target triple and object buffer. (Future implementations might create `DebugObject`s from a `LinkGraph` in other ways.) On success it will track it as the pending `DebugObject` for the `MaterializationResponsibility`.

This patch only implements the `ELFDebugObject` for `x86-64` targets. It follows the RuntimeDyld approach for debug object setup: it captures a copy of the input object, parses all section headers and prepares to patch their load-address fields with their final addresses in target memory. It instructs the plugin to report the section load-addresses once they are available. The plugin overrides `modifyPassConfig()` and installs a JITLink post-allocation pass to capture them.

Once JITLink emitted the finalized executable, the plugin emits and registers the `DebugObject`. For emission it requests a new `JITLinkMemoryManager::Allocation` with a single read-only segment, copies the object with patched section load-addresses over to working memory and triggers finalization to target memory. For registration, it notifies the `DebugObjectRegistrar` provided in the constructor and stores the previously pending`DebugObject` as registered for the corresponding MaterializationResponsibility.

The `DebugObjectRegistrar` registers the `DebugObject` with the target process. `llvm-jitlink` uses the `TPCDebugObjectRegistrar`, which calls `llvm_orc_registerJITLoaderGDBWrapper()` in the target process via `TargetProcessControl` to emit a `jit_code_entry` compatible with the GDB JIT interface [1]. So far the implementation only supports registration and no removal. It appears to me that it wouldn't raise any new design questions, so I left this as an addition for the near future.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html

Reviewed By: lhames

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

[Orc] Rename local variable to avoid confusion with equally-named class member (NFC)

[Orc] Fix a file header (NFC)

[JITLink] LinkGraph::getName() can be const

[JITLink] Remove some std::move(MemoryBufferRef) below createLinkGraphFromObject() (NFC)

[llvm-jitlink] Remove duplicate type defintion (NFC)

[lli] Add --jit-linker command line argument

The argument value determines the dynamic linker to use (`default`, `rtdyld` or `jitlink`). The JITLink implementation only supports in-process JITing for now. This is the first commit for the reviewed patch.

Reviewed By: lhames

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

Revert "[clangd] Use ML Code completion ranking as default."

CodeCompletionContext::Kind has 36 Kinds. The completion model currently
only handles categorical features of 32 cardinality.
Changing the datatype to uint64_t will solve the problem.

This reverts commit 438b5bb05a429d697674088d400e4800c1108658.

[OpenMP] Fix clang-cl build error regarding TSX intrinsics

Fix for https://bugs.llvm.org/show_bug.cgi?id=49339

The CMake check for the RTM intrinsics needs the -mrtm flag to be set
during the test. This way clang-cl correctly detects it has the
_xbegin() intrinsic. Otherwise, the CMake check fails.

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

[Driver] Fix -gz=zlib options for linker also on FreeBSD

ccb4124a4172 fixed translating -gz=zlib to --compress-debug-sections for
linker invocation for several ToolChains, but omitted FreeBSD.

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

[DAG] DAGCombiner::tryStoreMergeOfLoads - remove unused StartAddress variable. NFCI.

Noticed in "initialization is never read" clang-tidy warning - the only StartAddress set/used is inside the load combine loop.

[MCParser] Bring back srcmanager diagnostics in AsmParser

AsmParser may have no LLVMContext attached to it, which means after
5de2d189e6ad466a1f0616195e8c524a4eb3cbc0 everything goes to stderr.
Restore the old behavior.

[mlir] Use mlir::OpState::operator->() to get to Operation::getAttrs().

This is a preparation step to remove getAttrs() from OpState.

Support GDB remote g packet partial read

GDB remote protocol does not specify length of g packet for register read. It depends on remote to include all or exclude certain registers from g packet. In case a register or set of registers is not included as part of g packet then we should fall back to p packet for reading all registers excluded from g packet by remote. This patch adds support for above feature and adds a test-case for the same.

Reviewed By: labath

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

[clang][cli] NFC: Use .str() instead of operator<<

[AMDGPU] Fix "initialization is never read" clang-tidy warnings. NFCI.

[clang][cli] NFC: Use .str() instead of operator<<

[RISCV] Lower CONCAT_VECTORS to INSERT_SUBVECTOR nodes

The default expansion of CONCAT_VECTORS goes through the stack. This
patch avoids that penalty by custom-lowering CONCAT_VECTORS to a series
of INSERT_SUBVECTOR nodes. Futher optimizations are possible, but this
is a good start.

Reviewed By: craig.topper

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

[LLD][ELF][ARM] Refactor inBranchRange to use addend for PC Bias

In AArch32 ARM, the PC reads two instructions ahead of the currently
executiing instruction. This evaluates to 8 in ARM state and 4 in
Thumb state. Branch instructions on AArch32 compensate for this by
subtracting the PC bias from the addend. For a branch to symbol this
will result in an addend of -8 in ARM state and -4 in Thumb state.

The existing ARM Target::inBranchRange function accounted for this
implict addend within the function meaning that if the addend were
to be taken into account by the caller then it would be double
counted. This complicates the interface for all Targets as callers
wanting to account for addends had to account for the ARM PC-bias.

In certain situations such as:
https://github.com/ClangBuiltLinux/linux/issues/1305
the PC-bias compensation code didn't match up. In particular
normalizeExistingThunk() didn't put the PC-bias back in as Arm
thunks did not store the addend.

The simplest fix for the problem is to add the PC bias in
normalizeExistingThunk when restoring the addend. However I think
it is worth refactoring the Arm inBranchRange implementation so
that fewer calls to getPCBias are needed for other Targets. I
wasn't able to remove getPCBias completely but hopefully the
Relocations.cpp code is simpler now.

In principle a test could be written to replicate the linux kernel
build failure but I wasn't able to reproduce with a small example
that I could build up from scratch.

Fixes https://github.com/ClangBuiltLinux/linux/issues/1305

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

[clang][cli] NFC: Rename marshalling multiclass

The new name drops `String` from `MarshallingInfoStringInt`, which follows the naming convention of other marshalling multiclasses.

[LV] Add test cases that require a larger number of RT checks.

Precommit tests cases for D75981.

[MLIR][LinAlg] Detensorize interal function control flow.

This patch continues detensorizing implementation by detensoring
internal control flow in functions.

In order to detensorize functions, all the non-entry block's arguments
are detensored and branches between such blocks are properly updated to
reflect the detensored types as well. Function entry block (signature)
is left intact.

This continues work towards handling github/google/iree#1159.

Reviewed By: silvas

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

[clang][docs] Fix code blocks rendering

Some code blocks that render fine locally don't appear on the llvm.org website. Attempting to fix this by specifying the `text` type.

Revert "[X86] Fold shuffle(not(x),undef) -> not(shuffle(x,undef))"

This reverts commit 925093d88ae74560a8e94cf66f95d60ea3ffa2d3.

Causes an infinite loop when compiling some shuffles:

$ cat bugpoint-reduced-simplified.ll
target triple = "x86_64-unknown-linux-gnu"

define void @foo() {
entry:
  %0 = load i8, i8* undef, align 1
  %broadcast.splatinsert = insertelement <16 x i8> poison, i8 %0, i32 0
  %1 = icmp ne <16 x i8> %broadcast.splatinsert, zeroinitializer
  %2 = shufflevector <16 x i1> %1, <16 x i1> undef, <16 x i32> zeroinitializer
  %wide.load = load <16 x i8>, <16 x i8>* undef, align 1
  %3 = icmp ne <16 x i8> %wide.load, zeroinitializer
  %4 = and <16 x i1> %3, %2
  %5 = zext <16 x i1> %4 to <16 x i8>
  store <16 x i8> %5, <16 x i8>* undef, align 1
  ret void
}

$ llc < bugpoint-reduced-simplified.ll
<timeout>