Add extra tests for interleaving heuristics for different AArch64 CPUs.

This supports the lowering of intrinsic IS_CONTIGUOUS for array argument.
The argument of assumed rank is not supported since it is not implemented
yet as the procedure argument. Add TODO for it.

Reviewed By: PeteSteinfeld, jeanPerier

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

For the "all_of(setcc(x,y,eq)) -> PMOVMSKB(PCMPEQB())" fold, we failed to ensure that we could safely bitcast to <X x i8>, which in particular failed with boolean types

Thanks to @lerno for catching this and providing the test case

Instcombine prefers this canonical form (see getPreferredVectorIndex),
as does IRBuilder when passing the index as an integer so we may as
well use the prefered form from creation.

NOTE: All test changes are mechanical with nothing else expected
beyond a change of index type from i32 to i64.

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

It has been introduced since llvmorg-16-init-16838-gac1ffd3c

If both sides of AND operations are i1 splat_vectors or PTRUE node then we can
produce just i1 splat_vector as the result.

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

Adjust the GEPs to be non-trivial, to preserve test intent.

Check lines were regenerated for these.

The alignment changes in byval-2. look suspicious at first glance,
but actually only propagate pre-existing UB.

The current reduction logic tries to reproduce what a serial reduction
would produce, and just takes the first one that is still
interesting. We still have to wait for all others to complete though,
which at that point is just a waste.

This helps speed things up with long running reducers, which I
frequently have. e.g. for the added sleep test on my system, it took
about 8 seconds before this change and about 4 after.

https://reviews.llvm.org/D138953

HeaderSearch uses FileEntry::getName() to determine the best spelling of a
header. FileEntry::getName() is now the name of the *last* retrieved ref.
This means that when FileManager::getFile() hits an existing inode through a new
path, it changes the spelling of that header.

In the absence of explicit logic to track the preferred name(s) of header files,
we should avoid gratuitously calling getFile() with paths different than how
the header was originally included, such as the result of realpath().

The originally-specified path should be fine here:
 - if the same filemanager is being used for record/analysis, we'll hit the
   filename cache
 - if a different filemanager is being used e.g. preamble scenario, we should
   get the same result unless either the working directory has changed (which it
   shouldn't, else many other things will fail) or the file has gone/changed
   inode (in which case the old method doesn't work either)

Needless to say this is fragile, but talking to @kadircet offline, it's good
enough for our purposes for now.

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

Keeping bitcasts to preserve test behavior.

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the required foldHook changes and the TableGen machinery for generating `fold` method signatures using `FoldAdaptor` for ops, based on the value of `useFoldAPI` of the dialect. It may be one of 2 values, with convenient named constants to create a quasi enum. The new `fold` method will then be generated if `kEmitFoldAdaptorFolder` is used.

Since the new `FoldAdaptor` approach is strictly better than the old signature, part of this patch updates the documentation and all example to encourage use of the new `fold` signature.
Included are also tests exercising the new API, ensuring proper construction of the `FoldAdaptor` and proper generation by TableGen.

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

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the generation of generic adaptors through TableGen. These are essentially a generalization of Adaptors, as implemented previously, but instead of indexing into a `mlir::ValueRange`, they may index into any container, regardless of the element type. This allows the use of the convenient getter methods of Adaptors to be reused on ranges that are the result of some kind of mapping functions of an ops operands.
In the case of the fold API in the RFC, this would be `ArrayRef<Attribute>`, which is a mapping of the operands to their possibly-constant values.

Implementation wise, some special care was taken to not cause a compile time regression, nor to break any kind of source compatibility.
For that purpose, the current adaptor class was split into three:
* A generic adaptor base class, within the detail namespace as it is an implementation detail, which implements all APIs independent of the range type used for the operands. This is all the attribute and region related code. Since it is not templated, its implementation does not have to be inline and can be put into the cpp source file
* The actual generic adaptor, which has a template parameter for the range that should be indexed into for retrieving operands. It implements all the getters for operands, as they are dependent on the range type. It publicly inherits from the generic adaptor base class
* A class named as adaptors have been named so far, inheriting from the generic adaptor class with `mlir::ValueRange` as range to index into. It implements the rest of the API, specific to `mlir::ValueRange` adaptors, which have previously been part of the adaptor. This boils down to a constructor from the Op type as well as the verify function.

The last class having the exact same API surface and name as Adaptors did previously leads to full source compatibility.

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

Fix undefined behavior in `decodeSImmOperand` where we were left shifting
a signed value.

Just avoid crashing for now, we should be able to replace the blockaddresses
themselves.

BlockAddress::handleOperandChangeImpl assumes it can cast to Function.
The verifier seems nonexistent and the langref isn't particularly explicit
on what's allowed as a blockaddress operand. As far as I can tell bugpoint
isn't doing anything to handle this.

Something low level is broken with BlockAddress handling,
demonstrated by reduce-functions-blockaddress-wrong-function.ll.
The BasicBlock destructor of the deleted function is triggering replacement
of blockaddresses for the kept function in some cases. I've only half debugged
this but it seems like blockaddress is handled too-specially compared to other
Constants. I have tentative patches to allow any constant to be a blockaddress
input, but having the verifier check if it's really a function/block.

https://reviews.llvm.org/D140909

As Fortran 2018 C1553, if with BIND(C), the function result shall be an
interoperable scalar variable. As Fortran 2018 18.3.4(1), the
interoperable scalar variable is not a coarray, has neither the
ALLOCATABLE nor the POINTER attribute, and if it is of type character its
length is not assumed or declared by an expression that is not a constant
expression.

As Fortran 2018 18.3.1(1), if the type is character, the length type
parameter is interoperable if and only if its value is one.

Reviewed By: PeteSteinfeld, jeanPerier

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

This clang-format documentation file is auto-generated from Format.h,
so the fix should be applied there, or else it will be overwritten
whenever Format.h is modified and that file is regenerated.

This file builds correctly for me locally, but gives a warning about
not being able to lex the binary literal as C++ code.

This should fix the issue found by:
https://lab.llvm.org/buildbot/#/builders/92/builds/38522

We can just use the regular VisitCallExpr logic here, since we have the
pointer to initialize already on the stack.

This is unnecessary in the current state of the interpreter, but will ne
important later.

This new CPU was mentioned in Clang's release notes, but was missing
from LLVM's.

Reviewed By: dmgreen

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

[include-mapping] Fix the instructions for running stdlib recognizer. Mention python command explicitly. Remove angle brackets.

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

This reverts commit 879bfe6a.

owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.

We could have same SCEVs for the following expressions:
  zext(umin(x, y)) and umin(zext(x), zext(y));
  zext(umax(x, y)) and umax(zext(x), zext(y))
  sext(smin(x, y)) and smin(zsxt(x), sext(y));
  sext(smax(x, y)) and smax(sext(x), sext(y)).

Add a pass which do arith dialect ops optimization based on integer range analysis (only cmpi for now).

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

> Dependent access checks.

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

We previously ignored dependent access checks to private members.
These are visible only to the `RequiresExprBodyExpr` (through `PerformDependentDiagnositcs`) and not to the individual requirements.

---

> Non-dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53334
Access to members in a non-dependent context would always yield an
invalid expression. When it appears in a requires-expression, then this
is a hard error as this would always result in a substitution failure.

https://eel.is/c++draft/expr.prim.req#general-note-1
> Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]
> If the substitution of template arguments into a requirement would always result in a substitution failure, the program is ill-formed; no diagnostic required.

The main issue here is the delaying of the diagnostics.
Use a `ParsingDeclRAIIObject` creates a separate diagnostic pool for diagnositcs associated to the `RequiresExprBodyDecl`.
This is important because dependent diagnostics should not be leaked/delayed to higher scopes (Eg. inside a template function or in a trailing requires). These dependent diagnostics must be attached to the `DeclContext` of the parameters of `RequiresExpr` (which is the `RequiresExprBodyDecl` in this case).
Non dependent diagnostics, on the other hand, should not delayed and surfaced as hard errors.

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

The legwork for these was done by https://reviews.llvm.org/D138725. Here we're
just adding the arch names to the cmake files and linking them to
arm_min_SOURCES.

Reviewed By: MaskRay

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

Automatically generated by D130897. This fixed issue #58792.

Reviewed By: pengfei

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