We should see `NodeRole` information in the dump because that exposes how the
accessors will behave.

Functional changes in the dump:
* Surround Leaf tokens with `'`
* Append `Node` dumps with `NodeRole` information, except for unknown roles
* Append marks to `Node` dumps, instead of prepending

Non-functional changes:
* `::dumpTokens(llvm::raw_ostream, ArrayRef<syntax::Token>, const
SourceManager &SM)` always received as parameter a `syntax::Token *`
pointing to `Leaf::token()`. Changed the function to
`dumpLeaf(llvm::raw_ostream, syntax::Leaf *, const SourceManager&)`
* `dumpTree` acted on a Node, rename to `dumpNode`

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

psutil isn't reall a dependency of the test suite so this shouldn't be
unconditionally be imported here. Instead just check for the process name
by looking for the "a.out" string to get the bots green again.

friend declarations and declarations found in inline namespaces within
the target context.

Support -march=sapphirerapids for x86.
Compare with Icelake Server, it includes 14 more new features. They are
amxtile, amxint8, amxbf16, avx512bf16, avx512vp2intersect, cldemote,
enqcmd, movdir64b, movdiri, ptwrite, serialize, shstk, tsxldtrk, waitpkg.

Reviewed By: craig.topper

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

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

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

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

For the Windows GNU platform, CMAKE_FIND_LIBRARY_PREFIXES is a list
containing an empty string, which ended up in a regex capturing group,
which is invalid in CMake's regex engine. With this change, we get the
following:

  set(CMAKE_FIND_LIBRARY_PREFIXES "lib" "")
  set(CMAKE_FIND_LIBRARY_SUFFIXES ".dll.a" ".a" ".lib")
  get_system_libname(path/to/libz.dll.a zlib)
  message("${zlib}")

outputs z, as expected.

Patch By: haampie

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

as it's causing test failures.

This reverts commit 589ce5f7.

For some reason the ctor homing case was before the template
specialization case, and could have returned false too early.
I moved the code out into a separate function to avoid this.

Also added a run line to the template specialization test. I guess
all the -debug-info-kind=limited tests should still pass with =constructor,
but it's probably unnecessary to test for all of those.

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

If an error has occurred a symbol may have a DeclTypeSpec but no
valid DynamicType. There is no need to compute the size of erroneous
symbols.

Also, we only need to process object entities and procedure entities.
All other kinds of symbols can be skipped.

This fixes another problem revealed by https://bugs.llvm.org/show_bug.cgi?id=47265

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

warnings.

In passing, also teach the driver to map /std:c++latest to -std=c++20
not -std=c++2a.

If we use training algorithms that don't need partial rewards, we don't
need to worry about an ir2native model. In that case, training logs
won't contain a 'delta_size' feature either (since that's the partial
reward).

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

On Windows, 'env' or 'printenv' may not exist.

Also switch back to 'env' which is specified by POSIX.1-2017. 'printenv' is not
standard (I picked it because 'printenv' exists on GnuWin32 but 'env' does not).

Reviewed By: zequanwu

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

There was typo left from changes in CalculateSVEOffset where we moved
FPSR/FPCR offset calculation into WriteRegister and ReadRegister.

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

The trailing 'L' was missing in the expectation.

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

[LLDB] Fix how ValueObjectVariable handles DW_AT_const_value when the DWARFExpression holds the data that represents a constant value

In some cases when we have a DW_AT_const_value and the data can be found in the
DWARFExpression then ValueObjectVariable does not handle it properly and we end
up with an extracting data from value failed error.

The test is a very stripped down assembly file since reproducing this relies on the results of compiling with -O1 which may not be stable over time.

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

With FMF ( "nsz" and " reassoc") fold X/Sqrt(X) to Sqrt(X).

This is done after targets have the chance to produce a
reciprocal sqrt estimate sequence because that expansion
is probably more efficient than an expansion of a
non-reciprocal sqrt. That is also why we deferred doing
this transform in IR (D85709).

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

This goes with the proposal in D86403.

When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.

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

We would still need to waterfall if the value were somehow an AGPR,
and also need to explicitly copy to a VGPR.

PC-Relative addressing introduces a fair bit of complexity for correctly
eliminating TOC accesses. FastISel does not include any of that handling so we
miscompile code with -mcpu=pwr10 -O0 if it includes an external call that
FastISel does not handle followed by any of the following:

    Floating point constant materialization
    Materialization of a GlobalValue
    Call that FastISel does handle

This patch switches to SDISel for any of the above.

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

This is preparation for making clang default to -mtune=generic when no -march is specified. This will allow the default tuning to be "generic" even though our default march is "pentium4" or "x86-64".

To avoid llc lit test regressions, if no mcpu is specified, I've defaulted tune to use i586 to match the old tuning settings of no CPU. Some tests explicitly used -mcpu=generic which I've removed so they instead get this default of architecture features from generic and tune from i586.

I updated one llvm-mca test to check a different CPU since generic has a scheduler model now

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

SelectionDAG and GlobalISel take different failure paths for these and
end up producing different failure errors. Check both so the test
passes when the default is switched.

Also intercept these target functions on Linux.

We initially missed the subtract-immediate in this transformation.
This patch just adds that.

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

The static_assert macro broke on GCC when a scope had two asserts and a
condition that depended on a template parameter. Remove the macro and
rely on the compiler's C++11 static_assert feature.

The __has_feature macro was only used here to determine whether to
define the static_assert macro.

Reviewed By: mstorsjo, #libunwind

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

Add interceptors for the barrier variants of the "async and wait"
dispatch API family.

InstCombine currently has odd rules for folding insert-extract chains to shuffles,
so we miss collapsing seemingly simple cases as shown in the tests here.

But poison makes this not quite as easy as we might have guessed. Alive2 tests to
show the subtle difference (similar to the regression tests):
https://alive2.llvm.org/ce/z/hp4hv3 (this is ok)
https://alive2.llvm.org/ce/z/ehEWaN (poison leakage)

SLP tends to create these patterns (as shown in the SLP tests), and this could
help with solving PR16739.

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

That can cause problems for update_test_checks.py (it warns when updating this file).

It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.

Reviewed By: phosek

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

{builtin,runtime}_register_target passes a TOOLCHAIN_TOOLS list, whereas
{builtin,runtime}_default_target does notl. The explicit TOOLCHAIN_TOOLS
list matches what LLVMExternalProjectUtils would have set anyway,
barring some target-specific adjustments, and those target-specific
adjustments seem valuable, so let's drop the explicit TOOLCHAIN_TOOLS
list and let LLVMExternalProjectUtils take care of it.

Reviewed By: phosek

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

libtool already produces a table of contents, and ranlib just gives
spurious errors because it doesn't understand universal binaries.

Reviewed By: phosek

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