/data/llvm-project/mlir/lib/Dialect/Transform/IR/TransformOps.cpp:230:35: error: unqualified call to 'std::move' [-Werror,-Wunqualified-std-cast-call]
  patterns.try_emplace(attr, [f = move(fn)](RewritePatternSet &patternSet) {
                                  ^
                                  std::
1 error generated.

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

Add interface attribute to __sanitizer_internal_mem* declarations as
well, as otherwise some compilers (MSVC) will complain.

Add i8/i16/i24/i42 ADD/SUB test coverage

This function should be implemented for ops that work in one-shot
bufferization.

Reviewed By: springerm

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

D135716 introduced -ftrivial-auto-var-init=pattern where supported.
Unfortunately this introduces unwanted memset() for large stack arrays,
as shown by the new tests added for asan and msan (tsan already had this
test).

In general, the problem of compiler-inserted memintrinsic calls
(memset/memcpy/memmove) is not new to compiler-rt, and has been a
problem before.

To avoid introducing unwanted memintrinsic calls, we redefine
memintrinsics as __sanitizer_internal_mem* at the assembly level for
most source files automatically (where sanitizer_common_internal_defs.h
is included).

In few cases, redefining a symbol in this way causes issues for
interceptors, namely the memintrinsic interceptor themselves. For such
source files we have to selectively disable the redefinition.

Other alternatives have been considered, but simply do not work well in
the context of compiler-rt:

	1. Linker --wrap:  this does not work because --wrap only
	   applies to the final link, and would not apply when building
	   sanitizer static libraries.

	2. Changing references to memset() via objcopy:  this may work,
	   but due to the complexities of the build system, introducing
	   such a post-processing step for the right object files (in
	   particular object files defining memset cannot be touched)
	   seems infeasible.

The chosen solution works well (as shown by the tests). Other libraries
have chosen the same solution where nothing else works (see e.g. glibc's
"symbol-hacks.h").

v3:
- Don't use ALIAS() to alias internal_mem*() functions to
  __sanitizer_internal_mem*() functions, but just define them as
  ALWAYS_INLINE functions instead. This will work on darwin and windows.

v2:
- Fix ubsan_minimal build where compiler decides to insert
  memset/memcpy: ubsan_minimal has work without RTSanitizerCommonLibc,
  therefore do not redefine the builtins.
- Fix definition of internal_mem* functions with compilers that want the
  aliased function to already be defined before.
- Fix definition of __sanitizer_internal_mem* functions with compilers
  more pedantic about attribute placement around extern "C".

Reviewed By: vitalybuka, dvyukov

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

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

Also merge 32-bit/64-bit handling of G_CTPOP/G_CTLZ using legalIf()

Add a new transform op that applies patterns to a targeted payload op. Patterns can be registered by transform dialect extensions in a pattern registry.

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

Add a new interface `FindPayloadReplacementOpInterface` to specify ops that should be skipped when looking for payload replacement ops. Such ops are typically metadata-only ops.

With this change, we no longer need to maintain a custom TrackingListener in the tensor dialect.

Note: `CastOpInterface` by itself is not sufficient. Some metadata-only ops such as "tensor.reshape" are not casts, and it would be incorrect for them to implement the `CastOpInterface`.

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

Maps to amendment in under specification:
riscv-non-isa/rvv-intrinsic-doc#233

Signed-off-by: eop Chen <eop.chen@sifive.com>

No tests failed when I removed the hasBranchDivergence check, so
add one.

This fixes the largest remaining discrepancy between results of
computeKnownBits() and SimplifyDemandedBits(). We only care about
the multi-use case here, because the assume necessarily introduces
an extra use.

This patch extends existing IR combines for: fmul, fsub and fadd,
relying on all active predicate to also apply to their equivalent
undef (_u) intrinsics.

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

get rid of the SourceManager dependency -- getCanonicalPath doesn't use
other SourceManager fields.

If the ZExt can be lowered to a single ZExt to the next power-of-2 and
the remaining ZExt folded into the user, don't use tbl lowering.

Fixes #62620.

Reviewed By: efriedma

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

Replace the legacy legalizers for G_ADD/G_SUB with a pattern that should work for the full mixture of scalar/vector types we need to support for most opcodes.

If we can decide on this as a suitable pattern we can reuse it for the other op types, but G_ADD/G_SUB are the only ones that have decent legalizer test coverage at this stage.

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

This patch suggests to add a sentence in the introduction which clarifies
the aim of the dialect in one sentence. I hope that I understood it correctly.

For the `summary` fields, I have scrolled through the Bufferization page
(<https://mlir.llvm.org/docs/Bufferization>) and added missing summaries
or standardized existing ones to make the summaries easier to read.

Reviewed By: springerm

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

Reviewed By: RKSimon

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

These implement essentially the same thing, so normalize
ValueTracking to use SimplifyQuery. In the future we can directly
expose the SimplifyQuery-based APIs.

Extra test coverage for D150482.

This mitigates the compile-time regression from D151424. The use
of std::function is not necessary here, as we're passing in a
static function.

Fix isKnownNeverInfOrNaN() call in AMDGPU after ORE removal 97b5cc21

The X86SchedSapphireRapids.td file is automatically generated by
schedtool (D130897). Most of instruction's scheduling information
is from SapphireRapids tpt/lat data provided by intel doc. Some data
is from measured ADL-P data in uops.info. The rest instruction's
scheduling information is from skylake server schedule model in order
to get a relative complete model.

Reviewed By: LuoYuanke

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

Missed this in 97b5cc21.

The ORE argument threaded through ValueTracking is used only in a
single, untested place. It is also essentially never passed: The
only places that do so have been added very recently as part of the
KnownFPClass migration, which is vanishingly unlikely to hit this
code path. Remove this effectively dead argument.

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

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

This reverts commit fc1262bd.

This causes build bot failures because of a parser test case:
https://lab.llvm.org/buildbot/#/builders/139/builds/41961

... emitting them.

This makes later code easier to understand, since we emit the code
snippets line by line anyway.
It also fixes the weird underlinig of multi-line source ranges.

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

These helpers should not be part of the IR build unit.

The interface is now implemented on `builtin.unrealized_conversion_cast` with an external model.

Also rename the CastOpInterfaces Bazel target name to CastInterfaces to be consistent with the CMake target name.

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

and pass Record* pointers around as const.

Split the vop_type parameter to VPatBinaryVL_VF into vop1_type
and vop2_type. This will allows to be used for vfwadd.wf in
a future patch.

Allow WQM pass to insert transitions to exact mode among block
terminators, instead of forcing them to occur before terminators.

This should not yield any functional change, but allows block
splitting of control flow, such as that in D145329.

Reviewed By: arsenm

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

This codepath isn't exercised in-tree right now unfortunately, this only
happens when a dialect does not use the default entry points for types
parsing AND is extensible: both of these aren't the default settings and
the combination of them isn't common.

Fix #63058

Reviewed By: frasercrmck

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

Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef`
values instead of `ConstString`.

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