When we check for similarity, right now there is no order to how it is checked, except for via the suffix tree ordering.

We can reduce how much structural analysis we perform by checking the the regions in decreasing size. In doing so, we know that if two large sections match, each of their contained regions also match. This allows us to skip the structural checking for each smaller section. IT does require that we use the large regions as a "bridge" to create the canonical mapping between the two regions.

This reduces compile time significantly for some benchmarks. It will not perform as well for programs with many small items.

Recommit fixes the IRSimilarity tests.

Recommit of: 805ec19d

Reviewer: paquette
Differential Revision: https://reviews.llvm.org/D139338

Horizontal reductions still occur on RISC-V, despite the maximum SLP VF
reported back by TTI being 1, to disable SLP.
This can cause the cost model to think it can vectorize a gather into
smaller, widened loads, when it will actually fail to do so.
This should ultimately be fixed whenever SLP is re-enabled for RISC-V at
some point.

Reviewed By: reames

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

This is especially convenient when trying to resize the splat.

Reviewed By: jpienaar

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

A rare case where coalescing resulted in a hh32 (high32 of high64 of vector
register) subreg usage caused getSubReg() to fail as the vector reg does not
have that subreg in its subregs list, but rather h32 which was expected to
also act as hh32. See link below for the discussion when solving this.

Patch By: critson

Reviewed By: uweigand

Fixes: https://github.com/llvm/llvm-project/issues/61390

../llvm-project/lldb/include/lldb/Interpreter/ScriptedProcessInterface.h:61:12:
warning: implicit conversion from 'unsigned long long' to 'size_t' (aka 'unsigned int')
changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
../llvm-project/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp:275:39:
warning: result of comparison of constant 18446744073709551615 with expression
of type 'size_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]

This happens because size_t on 32 bit is 32 bit, but LLDB_INVALID_OFFSET is
UINT64_MAX. Return lldb::offset_t instead, which is 64 bit everywhere.

DoWriteMemory still returns size_t but this is because every other
Process derived thing does that. As long as the failure check works I think
it should be fine.

Reviewed By: mib

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

This reverts commit 8d2885c2.

I accidentally introduced an infinite loop in this patch, will return when this is fixed.

This models the approach used in LFTR. The short summary is that we need to prove the IV is not dead first, and then we have to either prove the poison flag is valid after the new user or delete it.

There are two key differences between this and LFTR.

First, I allow a non-concrete start to the IV. The goal of LFTR is to canonicalize and IVs with constant starts are canonical, so the very restrictive definition there is mostly okay. Here on the other hand, we're explicitly moving *away* from the canonical form, and thus need to handle non-constant starts.

Second, LFTR bails out instead of removing inbounds on a GEP. This is a pragmatic tradeoff since inbounds is hard to infer and assists aliasing. This pass runs very late, and I think the tradeoff runs the other way.

A different approach we could take for the post-inc check would be to perform a pre-inc check instead of a post-inc check. We would still have to check the pre-inc IV, but that would avoid the need to drop inbounds. Doing the pre-inc check would basically trade killing a whole IV for an extra register move in the loop. I'm open to suggestions on the right approach here.

Note that this analysis is quite expensive compile time wise. I have made no effort to optimize (yet).

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

If the global already exists, use its existing type, so we don't
try to mix literal and non-literal structs among the elements.

Fixes https://github.com/llvm/llvm-project/issues/56809.

D146089's author discovered that our diagnostics for always/no inline
would null-dereference when used in a template. He fixed that by
skipping in the dependent case.

This patch makes sure we diagnose these after a template instantiation.
It also adds infrastructure for other statement attributes to add
checking/transformation.

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

This is a follow up to one of the side discussions on D146429.  There are two semantic changes contained here.

The motivation for the change to the legality condition introduced in D146429 comes from the fact that we only check the post-inc form. As such, as long as the values of the post-inc variable don't self wrap, it's actually okay if we wrap past the starting value of the pre-inc IV.

Second, Nikic noticed during review that the test changes changed behavior for TC=0 (i.e. N=0 in the tests).  On more careful inspection, it became apparent that the previous manual expansion code was incorrect in the case where the primary IV could wrap without poison, and started with the limit value (i.e. i8 post-inc starts at 255 for 0 exit test, implying pre-inc starts with 0).  See @wrap_around test for an example of the (previous) miscompile.

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

Derived from an observation by @nikic on D146457.

The dyanmic type must be carried over in a PolymorphicValue when the address is
loaded from an unlimited polymorphic allocatable.

Reviewed By: PeteSteinfeld

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

When this interface is used, a call to inferReturnTypeComponents()
is generated on creation and verification of the op.
A few changes were required in inferReturnTypeComponents():
- Emit error when it fails.
  The verifier calls this method now, and it is preferable to
  indicate what caused the failure.
- Fix the inferred return shapes so they have a type too.

Reviewed By: rsuderman

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

Named sequences introduce an additional abstraction and reuse capability
to the transform dialect. They can be though of as macros parameterized
with handles that can be invoked in places where a transform dialect
operation is expected. Such reuse was previously not possible in the
dialect and required dynamic construction of the transform IR from the
client language. Named sequences are intentionally restricted to
disallow recursion, as it could make the dialect accidentally
Turing-complete, which isn't desired at this point.

Reviewed By: springerm

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

We were accidentally issuing "overloaded 'operator[]' with more than
one parameter is a C++2b extension" with -pedantic because it was an
ExtWarn diagnostic rather than a Warning. This corrects the diagnostic
category and adds some test coverage.

Fixes #61582

ifuncs can't take part of the whole-program devirtualization so no need them to be copied to the merged module.
The corresponding resolver function also kept out which caused the crash.

Fixes #60962 #57870

Reviewed By: tejohnson

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

This invariant was introduced in 8f3d1690.

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

Reviewed By: arichardson, emaste

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

Patch represents the clang part of changes in D143347

Reviewed By: balazske

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

~~

Huawei RRI, OS Lab

This patch is to isolate the lax vector conversions warning only for PPC,
the reason is that SystemZ wants different logic in terms of
vector bool compatibility.

Reviewed By: lei

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

This patch adds alloca address space information to the data layout interface
and implementation in the DLTI dialect. This is needed for targets that use
separate address spaces for local/stack data.

Reviewed By: ftynse, krzysz00

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

Help catch regressions from D145650 that were only noticed on EXPENSIVE_CHECKS builds

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

Fixes #61441.

Currently, Clang stores `nullptr` in the parameter lists inside
`FunctionProtoTypeLoc` if `__fp16` is used without pointer qualifiers.

Any code path that calls `Declarator::setInvalidType()` before
`GetFullTypeForDeclarator` will lead to the same problem downstream.

The relevant code is:
```cpp
if (D.isInvalidType())
  return Context.getTrivialTypeSourceInfo(T);

return GetTypeSourceInfoForDeclarator(state, T, TInfo);
```

`GetTypeSourceInfoForDeclarator` sets the parameter `Decl`, but we can't
call it when `isInvalidType() == true` as this causes other assertion
failures that seem harder to fix.

Reviewed By: kadircet

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

This prevents unused nodes from being created if the constant check fails.

Noticed while triaging D127115 regressions

This patch supports the processing of dialect attributes attached to top-level
module-type operations during MLIR-to-LLVMIR lowering.

This approach modifies the `mlir::translateModuleToLLVMIR()` function to call
`ModuleTranslation::convertOperation()` on the top-level operation, after its
body has been lowered. This, in turn, will get the
`LLVMTranslationDialectInterface` object associated to that operation's dialect
before trying to use it for lowering prior to processing dialect attributes
attached to the operation.

Since there are no `LLVMTranslationDialectInterface`s for the builtin and GPU
dialects, which define their own module-type operations, this patch also adds
and registers them. The requirement for always calling
`mlir::registerBuiltinDialectTranslation()` before any translation of MLIR to
LLVM IR where builtin module operations are present is introduced. The purpose
of these new translation interfaces is to succeed when processing module-type
operations, allowing the lowering process to continue and to prevent the
introduction of failures related to not finding such interfaces.

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

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

This reverts commit e4c1dfed.

Fix warnings in AttrTypeSubElements.h (below) with GCC 9.4.0.

```
mlir/lib/IR/ExtensibleDialect.cpp:443:62:   required from here
mlir/include/mlir/IR/AttrTypeSubElements.h:412:37: warning: parameter ‘derived’ set but not used [-Wunused-but-set-parameter]
  412 | void walkImmediateSubElementsImpl(T derived,
      |                                   ~~^~~
```

Reviewed By: mehdi_amini

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

This is a copy of the vecreduce_or tests but with comparison
to -1 rather than 0.

This reverts commit 614c63be.

This adds a new macro to the UnixSignals subclasses, ADD_SIGCODE.

ADD_SIGCODE(4, ILL_ILLOPC, 1, "illegal opcode");

Adds a sigcode to signal 4. That code is ILL_ILLOPC and we expect
its value to be 1. When compiling on a system that matches the class
e.g. FreeBSD for FreeBSDSignals, the macro will check that that is true.

When you're not on FreeBSD we just use the number 1, and ILL_ILLOPC
won't be defined to anything because we don't include csignal.

Example error:
LinuxSignals.cpp:52:3: error: static_assert failed due to requirement
'ILL_COPROC == 9' "Value mismatch for signal code ILL_COPROC"

Reviewed By: arichardson

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

This avoids having to cast the result of the builder to
GetElementPtrInst.

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

The exit code of the (funky) test inferior depends on the linux kernel
version (changed some time between 5.15 and 6.1).