Implement mul, div, rem, etc. compound assign operators.

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

Just like we do with all the other Check* functions.

This way we can check for this flag in the new interpreter as well.

The `lower_vectors` operation of the transform dialect takes a lot of
arguments to build.
In order to make C++ code easier to work with when using this
instruction, introduce a new structure, named `LowerVectorsOptions`, that
aggregates all the options that are used to build this instruction.

This allows to use patterns like:
```
LowerVectorsOptions opts;
opts.setOptZ(...)
  .setOptY(...)...;
builder.create<LowerVectorsOp>(target, opts);
```

Instead of having to pass all N options directly to the builder and set
them in the right order.

NFC

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

This commit introduces LLVM's `MemoryEffects` attribute and replaces the
deprecated usage of `llvm.readnone` in the LLVM dialect.
The absence of the attribute on a `LLVMFuncOp` implies that it might
access all kinds of memory. This semantic corresponds to `llvm::Function`'s
behaviour.

Depends on D142002

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

Simplify the handling of silenceable failures in the transform dialect.
Previously, the logic of `TransformEachOpTrait` required that
`applyToEach` returned a list of null pointers when a silenceable
failure was emitted. This was not done consistently and also crept into
ops without this trait although they did not require it. Handle this
case earlier in the interpreter and homogeneously associated preivously
unset transform dialect values (both handles and parameters) with empty
lists of the matching kind. Ignore the results of `applyToEach` for the
targets for which it produced a silenceable failure. As a result, one
never needs to set results to lists containing nulls. Furthermore, the
objects associated with transform dialect values must never be null.

Depends On D140980

Reviewed By: nicolasvasilache

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

Use the recently introduced transform dialect parameter mechanism to
perform controllable multi-size tiling with sizes computed at the
transformation time rather than at runtime.

This requires to generalize tile and split structured transform
operations to work with any transform dialect handle types, which is
desirable in itself to avoid unchecked overuse of PDL OperationType.

Reviewed By: shabalin

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

Similarly to what backref() does, add an "easy path" to slow()
that can handle some non-branching cases, in particular simple
character matches.

This has the dual effect of reducing the number of characters we
need to match, and the number of states in the NFA.

This reduces FileCheck runtime on vloxseg.c from 17s to 12s on
my machine.

Just like we do for record members, diagnose uninitialized array record
fields.

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

They were pointed out in the review of https://reviews.llvm.org/D140875

We often visit the same variable multiple times, e.g. once when checking
its initializer and later when compiling the function. Unify both of
those in visitVarDecl() and do the returning of the value in
visitDecl().

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

Adds intrinsics for the following instructions:

* WHILEGE (predicate pair)
* WHILEGT (predicate pair)
* WHILEHI (predicate pair)
* WHILEHS (predicate pair)
* WHILELE (predicate pair)
* WHILELO (predicate pair)
* WHILELS (predicate pair)
* WHILELT (predicate pair)

I've added an opcode selector called SelectOpcodeFromVT to
AArch64ISelDAGToDAG.cpp that we will extend in future to
select opcodes from different MVTs. For now, the only use is
for selecting predicate types.

NOTE: These intrinsics are still in development and are subject
to future changes.

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

This commit ensures that all functions produced by `FuncToLLVM` drop the
llvm.linkage attribute. Furthermore, it adds a small test that checks if
the readnone attribute is preserved.

Reviewed By: gysit

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

NFC

Turning idempotent `atomicrmw`s into `load atomic` is perfectly legal
with respect to how the loading happens, but it may not be legal for the
whole program semantic.

Indeed, this optimization removes a store that may have some effects on
the legality of other optimizations.
Essentially, we lose some information and depending on the backend
it may or may not produce incorrect code, so don't do it!

This fixes llvm.org/PR56450.

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

In the LLVM IR dialect, `LLVMVoidType` is used to model the return type
of LLVM IR functions with no return value. This is inconsistent with
MLIR APIs, which expect a function with no return value to have an
empty return type. Handle this special case in `LLVMFuncOp` to avoid
mismatches between the number of return values and return types between
caller and callee.

Reviewed By: ftynse

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

It was using an incorrect attribute type, but the test was still passing
because of the value being present in the output.

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

`-loongarch-numeric-reg` for llvm-mc and llc.
`-M numeric` (which matches GNU objdump) for llvm-objdump and llvm-mc.

Reviewed By: SixWeining

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

These pattern names are inconsistent with current update_checks.py.

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

The code below currently prints less accurate values only on Windows 32-bit. On Windows, the default precision control on x87 is only 53-bit, and FADD triggers rounding with that precision, so the final result may be less accurate. This revision avoids less accurate conversions by using library calls instead.

```

int main() {
    int64_t n = 0b0000000000111111111111111111111111011111111111111111111111111111;
    printf("%lld, %.0f, %.0f", n, (float)n, (float)(uint64_t)n);

    return 0;
}
```

Reviewed By: craig.topper, lebedev.ri

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

This patch drops the ZeroBehavior parameter from bit counting
functions like countLeadingZeros.  ZeroBehavior specifies the behavior
when the input to count{Leading,Trailing}Zeros is zero and when the
input to count{Leading,Trailing}Ones is all ones.

ZeroBehavior was first introduced on May 24, 2013 in commit
eb91eac9.  While that patch did not
state the intention, I would guess ZeroBehavior was for performance
reasons.  The x86 machines around that time required a conditional
branch to implement countLeadingZero<uint32_t> that returns the 32 on
zero:

        test    edi, edi
        je      .LBB0_2
        bsr     eax, edi
        xor     eax, 31
.LBB1_2:
        mov     eax, 32

That is, we can remove the conditional branch if we don't care about
the behavior on zero.

IIUC, Intel's Haswell architecture, launched on June 4, 2013,
introduced several bit manipulation instructions, including lzcnt and
tzcnt, which eliminated the need for the conditional branch.

I think it's time to retire ZeroBehavior as its utility is very
limited.  If you care about compilation speed, you should build LLVM
with an appropriate -march= to take advantage of lzcnt and tzcnt.
Even if not, modern host compilers should be able to optimize away
quite a few conditional branches because the input is often known to
be nonzero from dominating conditional branches.

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

I am getting this error with `check-flang`:
```
ld.lld: error: undefined symbol: mlir::SuccessorRange::SuccessorRange(mlir::Operation*)
>>> referenced by Operation.h:549 (/llvm-project/llvm/../mlir/include/mlir/IR/Operation.h:549)
>>>               CMakeFiles/FlangRuntimeTests.dir/Allocatable.cpp.o:(mlir::Operation::getSuccessors())
```

The buildbots are okay, so I guess it has something to do with
gcc-9 that I am using.

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

This lets users of FunctionOpInterface finally have the
name/visibility accessors from SymbolOpInterface. This also
lets us remove the clunky "getName" method from FunctionOpInterface.

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

This allows for interfaces to define a set of "base classes",
which are interfaces whose methods/extra class decls/etc.
should be inherited by the derived interface. This more
easily enables combining interfaces and their dependencies,
without lots of awkard casting. Additional implicit conversion
operators also greatly simplify the conversion process.

One other aspect of this "inheritance" is that we also implicitly
add the base interfaces to the attr/op/type. The user can still
add them manually if desired, but this should help remove some
of the boiler plate when an interface has dependencies.

See https://discourse.llvm.org/t/interface-inheritance-and-dependencies-interface-method-visibility-interface-composition

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

SymbolOpInterface overrides the base classof to provide support
for optionally implementing the interface. This is currently placed
in the extraClassDeclarations, but that is kind of awkard given that
it requires underlying knowledge of how the base classof is implemented.
This commit adds a proper "extraClassOf" field to allow interfaces to
implement this, which abstracts away the default classof logic.

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

There are very few instances in which we use multiple files
for interface definitions (none upstream), and this allows
for including interfaces that shouldn't be generated (for
interface inheritance, dependencies, etc.)

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

We have WIP Fixables for local variables and this central part of the machinery
was dropping Fixables attached to local variables instead of keeping those and
dropping everything else.
We are in the process of rewriting our patches for emitting fixits after we
discovered a conceptual problem in our design.
That is why there's currently no tests that would've detected the issue but
that will change very shortly.

This reverts commit c79635cc. Since I
forgot the case for 32-bit machine.

mention developers to remember to touch the serializer after them
modified the field of decls

It is easy for the developers to forget to touch the serializer after
they add new field to decls. Then if the existing tests fail to catch
such cases, it may be a bug report from users some day. And it is
time-consuming to solve such bugs.

To mitigate the problem, I add the static_asserts in the serializer. So
that the developers can understand they need to modify the serializer
after they saw the static assertion failure. Although this can't solve
all the problems, I feel the current status can be much better.

Reviewed By: erichkeane

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

Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.

This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.

The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.

Fixes: #58168

Reviewed By: nickdesaulniers, thegameg

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

Reviewed By: vitalybuka

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

In non-coalescing IntervalMaps the value type should not be requried to be
equality-comparable.