If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.

In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.

Fixes https://github.com/llvm/...

Fixes PR57976.

Reviewed By: erichkeane, arichardson, MaskRay

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

Previously we stripped Weak flags from JITDylib symbol table entries once they
were resolved (there was no particularly good reason for this). Now we want to
retain them and query them when setting the Linkage on external symbols in
LinkGraphs during symbol resolution (this was the motivation for 75404e9e).
Making weak linkage of external definitions discoverable in the LinkGraph will
in turn allow future plugins to implement correct handling for them (by
recording locations that depend on exported weak definitions and pointing all
of these at one chosen definition at runtime).

Currently funciton lookup in the expression evaluator
fails to disambiguate member functions the are overloaded
on lvalue/rvalue reference-qualifiers. This happens because
we unconditionally set a `FunctionPrototype`s
`ExtProtoInfo::RefQualifier` to `RQ_None`. We lose
the ref-qualifiers in the synthesized AST and `clang::Sema`
fails to pick a correct overload candidate.

DWARF emits information about a function's ref-qualifiers
in the form of a boolean `DW_AT_rvalue_reference` (for rvalues)
and `DW_AT_reference` (for lvalues).

This patch sets the `FunctionPrototype::ExtProtoInfo::RefQualifier`
based on the DWARF attributes above.

**Testing**

* Added API test

llvm/llvm-project issue #57866

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

Expanded in SelectionDAGBuilder similar to llvm.fmuladd.

Reviewed By: frasercrmck, simoll

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

If any of the operands for FCmpOp is a vector, returns a vector<Nxi1>,
rather than an i1 type result.

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

The push/pop context APIs are deprecated in HIP, and keeping the
default device set is handled in IHP using hipSetDevice().

Reviewed By: ThomasRaoux

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

Fix regression https://github.com/llvm/llvm-project/issues/56952 for Clang CodeGen on Windows. In the Windows ABI the instruction sequence that is expanded from CALL_RVMARKER should use RCX as target register and not RDI.

Reviewed By: rnk, fhahn

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

It is useful for PatternRewriter listeners to know the values that are
replacing the op in addition to only the fact of the op being replaced
for being able to keep track of changes or for debugging.

Reviewed By: Mogball

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

These two patterns are not working as intended, as shown in D134022.
They need to insert the value into the new register, not override it.

The ptxas assembler does not allow the `-g` flag along with
optimizations. Normally this is degraded to line info in the driver, but
when using LTO we did not have this step and the linker wrapper was not
correctly degrading the option. Note that this will not work if the user
does not pass `-g` again to the linker invocation. That will require
setting some flags in the binary to indicate that debugging was used
when building.

This fixes #57990

Reviewed By: jdoerfert

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

My original intent had been to reuse this for arithmetic instructions as well, but due to the availability of a immediate splat encoding there, we will need different heuristics.  So specialize the existing code for the store case.

The utility function should live in `StaticValueUtils.h` as it provides
a convenient way to convert a vector of OpFoldResults into a vector of
Values.

Reviewed By: nicolasvasilache, cota

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

We currently always specify the index (even if we set it to -1), and a future patch will need to adjust this method to make it more compatible with getScalarizationOverhead

This is still undocumented and unsupported, but if someone passed it before you
would end up with a missing file error since this takes an argument that
wouldn't be handled.

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

With the CMake file as written, if code elsewhere had set ROCM_PATH,
then HIP_PATH would not be set, breaking the rest of the ROCm
execution utility handling.

Reviewed By: mehdi_amini

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

Summary:
Most of the code that gets `iterator_types` from LinalgInterface is forced to
extract values from an `Attribute`. As a result, the usage pattern looks like
this:

```
SmallVector<StringRef> iterators = llvm::to_vector<4>(linalgOp.iterator_types().getAsValueRange<StringAttr>());
```

It also forces all operations that implement LinalgOp interface to have
`iterator_types` attribute even when the information can be easily infered from
other parameters.

In perfect future, `getIteratorTypeArray` should be the only method to get
iterator types from the interface. The default implementation can rely on
`iterator_types` attribute though.

The name `getIteratorTypeArray` was picked to be consistent with existing
`getIndexingMapsArray`.

This patch add a few sample usages. More cleanups will follow.

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

Follow up to D133580; adjust the cost model to prefer uniform store lowering for scalable stores which are unpredicated.

The impact here isn't in the uniform store lowering quality itself. InstCombine happily converts the scatter form into the single store form. The main impact is in letting the rest of the cost model make choices based on the knowledge that the vector will be scalarized on use.

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

Instead of accumulating all extraction costs separately and then adjusting for repeated subvector extractions, this patch collects all the extractions and then converts to calls to getScalarizationOverhead to improve the accuracy of the costs.

I'm not entirely satisfied with the getExtractWithExtendCost handling yet - this still just adds all the getExtractWithExtendCost costs together - it really needs to be replaced with a "getScalarizationOverheadWithExtend", but that will require further refactoring first.

This replaces my initial attempt in D124769.

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

As reported in GH #57945, this would crash because the decl context for
the lambda was being loaded via 'getNonClosureContext', which only gets
CODE contexts, so a global lambda was getting 'nullptr' here instead.
This patch does some work to make sure we get a valid/valuable
declcontext here instead.

A recent libcxx change renamed all internal variables starting with
`__`. As such, `std::reverse_iterator::__t` was renamed to
`std::reverse_iterator::__t_`. This breaks the `import-std-module`
tests with newer libcxx versions. Since this variable is deprecated
in libcxx anyway, this patch simply removes the explicit `ValueCheck`
on the variable name. We don't lose any interesting test-case here
since the purpose of the test is to see if we can call functions
from the `std` module.

We can now re-enable the tests on Darwin for all buildbot Clang
compiler variants.

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

With older DWARF versions we don't encode the enum's underlying
type in DWARF. In those cases LLDB sign-extends the bitfield as
a signed integer. Without the actual enum type being present in
DWARF there's not much we can do.

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

This seems to be beneficial overall, except for midpoint-int.ll .

The X86 backend seems to generate zeroing that are not necesary.

Reviewed By: shchenz

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

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

Fix build failure in:

  https://lab.llvm.org/buildbot/#/builders/36/builds/25424
  error: comparison of integers of different signs:
  'const unsigned long' and 'const int' [-Werror,-Wsign-compare]

  Reviewed By: Orlando

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

VE doesn't have FPOW instruction, so this patch makes llvm expand it.

Reviewed By: efocht

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

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

This revision refactors gpu block id generator lambda that is used in the transform dialect. It removes the lambda  and instead uses a static function that's name generateGpuBlockIds.

It also simplifies arguments that the function takes.

Reviewed By: nicolasvasilache

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

When running `target module lookup` command, show the name of absolute
symbols. Also fix indentation issue after printing an absolute symbol.

Reviewed By: clayborg, DavidSpickett

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

This adds a line break between each result address in the output of the
lldb command `target modules lookup`. Before this change, a new address
result will be printed on the same line as the summary of the last
result, making the output difficult to view.

Also adds a test for this command.

Reviewed By: labath

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

Simplifies the diff for D134697

The expanded values when rewriting exit values need to preserve LCSSA.
Ask SCEVExpander to preserve LCSSA to ensure that.

Fixes #58007.

A given function is compatible with all previous arch versions.
To avoid compering values of the attribute this logic adds all predecessor
architecture values.

Reviewed By: dmgreen, DavidSpickett

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

This updates checkFunctionMemoryAccess() to infer a precise
FunctionModRefBehavior, rather than an approximation split into
read/write and argmemonly.

Afterwards, we still map this back to imprecise function attributes.
This still allows us to infer some cases that we previously did not
handle, namely inaccessiblememonly and inaccessiblemem_or_argmemonly.
In practice, this means we get better memory attributes in the
presence of intrinsics like @llvm.assume.

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

Currently if both LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY (only
applies to static library) and LIBCXX_ENABLE_ABI_LINKER_SCRIPT (only
applies to shared library) are enabled, the former will be silently
ignored. The shared library will use a linker script, while the
static library fails to link libc++abi.a entirely.

This is caused by what appears to be an implementation bug: The
LIBCXX_STATICALLY_LINK_ABI_IN_*_LIBRARY options are declared as
dependent options of LIBCXX_ENABLE_STATIC_ABI_LIBRARY, rather than
simply using it as the default value.

Of course, the combination of
LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY and
LIBCXX_ENABLE_ABI_LINKER_SCRIPT still results in a cmake error,
because these would be conflicting requests for the shared library.

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