Group switch cases by opcode:
- VFCMULCPH
- VFCMULCSH
- VFMULCPH
- VFMULCSH

Reviewed By: craig.topper

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

Group switch cases by opcode:
- VFCMADDCPH
- VFCMADDCSH
- VFMADDCPH
- VFMADDCSH

Reviewed By: craig.topper

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

This extends a similar pattern from D125500.
If we know that operand 1 (RHS) of a subtract is itself a
non-overflowing subtract from operand 0 (LHS), then the
final/outer subtract is also non-overflowing:
https://alive2.llvm.org/ce/z/Bqan8v

InstCombine uses this analysis to trigger a narrowing
optimization, so that is what the first changed test shows.

The last test models the motivating case from issue #48013.
In that example, we determine 'nsw' on the first sub from
the srem, then we determine that the 2nd sub can be narrowed,
and that leads to eliminating both subtracts.

This works for unsigned sub too, but I left that out to keep
the patch minimal. If this looks ok, I will follow up with
that change. There are also several missing subtract narrowing
optimizations demonstrated in the tests above the diffs shown
here - those should be handled in InstCombine with another set
of patches.

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

At the moment, this just gets the infrastructure in place.  Following changes will start using this in non-trivial ways.

Depends on D124023

Reviewed By: Mogball, rriddle

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

num_images had previously been added to the list of intrinsics
before the type team_type had been implemented. Now that team_type
is implemented, add the num_images call that has the team argument.
Update the semantics tests for num_images.

Reviewed By: craig.rasmussen

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

We decided that we want to use clang-format for libc++ but we haven't decided yet how the code should be formatted. We should probably discuss things on discord. This PR is mostly to show how the clang-format would look like and to commit to one once we decided on it. I'll remove the `<string>` diff when I commit this PR.

Reviewed By: ldionne

Spies: EricWF, dschuff, krytarowski, fedor.sergeev, aheejin, mstorsjo, phosek, abrachet, libcxx-commits, arichardson

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

For reference, this test creates about 1.5G in the cache
directory. By default this will go to ~/.cache/clang/
which can fill up quick. This changes the test to put the
cache path in lit temp directories. Size considerations
aside it makes sense for tests to be hermetic and not
touch global system state.

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

This patch allows attaching user information, called "values" to each
identifier. The values are used to carry information along with variables and
are also used to determine if two variables are identical.

This patch is part of a series of patches to allow attaching user information
with variables in Presburger library.

Reviewed By: ftynse

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

Follow on to https://reviews.llvm.org/D108352, also check for the
definition of __LONG_DOUBLE_128__ before using it (because AIX doesn't
enable it by default).

Reviewed By: xingxue

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

Depends on D126215.

This allows configuring LLVM unwinder separately from the C++ library
matching how we configure it in libcxx.

This also applies changes made to libunwind+libcxxabi+libcxx in D113253
to compiler-rt.

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

The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class.

Reviewed By: #libc, ldionne

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

Reviewed By: martong

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

Mostly about allowing reuse in an upcoming patch, but also makes the code slightly easier to follow.

Depends on D126127

Reviewed By: martong

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

This is an initial step of removing the SimpleSValBuilder abstraction. The SValBuilder alone should be enough.

Reviewed By: martong

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

This patch introduces a generic data-flow analysis framework to MLIR. The framework implements a fixed-point iteration algorithm and a dependency graph between lattice states and analysis. Lattice states and points are fully extensible to support highly-customizable analyses.

Reviewed By: phisiart, rriddle

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

Traverse through freeze when checking if base is constant

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

The combine step for shufflevector will sometimes replace undef in the mask
with a defined value. This can cause an infinite loop in some cases as another
combine will then put the undef back in the mask.

This patch fixes the issue so that undefs are not replaced when doing a combine.

Reviewed By: ZarkoCA, amyk, quinnp, saghir

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

Also complete the set by adding a variant of depthwise 1d convolution
with the multiplier != 1.

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

This redoes D103040 in a way that `AlwaysIncludeTypeForTemplateArgument = false`
policy is honored for printing template specialization types.
This can be seen for example when printing a canonicalized
dependent TemplateSpecializationType which has integral arguments.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: v.g.vassilev

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

Introduce a transform dialect op that allows one to attempt different
transformation sequences on the same piece of payload IR until one of them
succeeds. This op fundamentally expands the scope of possibilities in the
transform dialect that, until now, could only propagate transformation failure,
at least using in-tree operations. This requires a more detailed specification
of the execution model for the transform dialect that now indicates how failure
is handled and propagated.

Transformations described by transform operations now have tri-state results,
with some errors being fundamentally irrecoverable (e.g., generating malformed
IR) and some others being recoverable by containing ops. Existing transform ops
directly implementing the `apply` interface method are updated to produce this
directly. Transform ops with the `TransformEachTransformOpTrait` are currently
considered to produce only irrecoverable failures and will be updated
separately.

Reviewed By: springerm

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

Adds option to print the contents of the Inline Advisor after each SCC Inliner pass

Reviewed By: mtrofin

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

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

This is possibly somewhat subjective, but having an explicitly named flag to track the property required and code structure that more closely matches phase 1/2 of the dataflow seems much easier to read.

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

This fixes https://github.com/llvm/llvm-project/issues/52873.
Don't warn in C++2A mode (and newer), as signed left shifts
always wrap and never overflow. Ref. -
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html.

We are planning on making LTO the default compilation mode for
offloading. In order to make sure it works we should run these tests on
the test suite. AMDGPU already uses the LTO compilation path for its
linking, but in LTO mode it also links the static library late.

Performing LTO requires the static library to be built, if we make the
change this will be a hard requirement and the old bitcode library will
go away. This means users will need to use either a two-step build or a
runtimes build for libomptarget.

Reviewed By: JonChesterfield

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

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

The error used to look like this:

  ld64.lld: error: undefined symbol: _foo
  >>> referenced by /path/to/bar.o

Now it displays the name of the function that contains the undefined
reference as well:

  ld64.lld: error: undefined symbol: _foo
  >>> referenced by /path/to/bar.o:(symbol _baz+0x4)

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

The `llvm/test/CodeGen/Thumb/frame-chain.ll`, recently added by D125094,
currently fails when expensive checks are enabled due to a tMOVr
instruction that is only valid from V6 onwards.

The use of the invalid instruction is unrelated to the contents of the
original patch, and continues to be triggered by this test if its
CodeGen changes are reverted, so this patch updates the test to use V6-M
while the issue is not resolved.

The instruction was skipped in the earlier large patch adding
VOP2, https://reviews.llvm.org/D126917.

Reviewed By: rampitec, #amdgpu

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