This is generally a better default for tools other than the compiler, which
shouldn't assume a PCH file on disk is something they can consume.

Preserve the old behavior in places associated with libclang/c-index-test
(including ASTUnit) as there are tests relying on it and most important
consumers are out-of-tree. It's unclear whether the tests are specifically
trying to test this functionality, and what the downstream implications of
removing it are. Hopefully someone more familiar can clean this up in future.

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

Fold references to the intrinsic function DIM with constant real
arguments.  And clean up folding of comparisons with NaNs to address
a problem noticed in testing -- NaNs should successfully compare
unequal to all values, including themselves, instead of failing all
comparisons.

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

A typical problem with missing a token is that the missing
token is at the end of a line.  The problem with this is that
the error message gets reported on the start of the following
line (which is where the next / invalid token is) which can
be confusing.

Handle this by noticing this case and backing up to the end of
the previous line.

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

This patch adds 32-bit AIX RUN lines to several test cases, along with the
addition of one new test case, to prepare for future codegen changes involving
the PPCISD::SCALAR_TO_VECTOR_PERMUTED node on 32-bit mode.

Only fold for uniform values on pre-GFX9 chips. GFX9+ allow us
to keep the calculation entirely on the SALU.

For subtargets where integer multiplication isn't full-rate, avoid
folding if the multiply has too many uses.

Finally, we expand 64x32 and 64x64 multiplies here as well, if they
feed into an addition. This results in better code generation than
the generic expansion for such multiplies because we end up using
the accumulator of the MAD instructions.

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

Before this change GVNSink pass suffers from stack overflow while processing self referenced instruction in unreachable basic block.
According [1] and [2] it's reasonable to make pass resistant against self referencing instructions.
To fix issue we skip sinking analysis when we reach instruction coming from unreachable block.

[1] https://groups.google.com/g/llvm-dev/c/843Tig9IzwA
[2] https://lists.llvm.org/pipermail/llvm-dev/2015-February/082629.html

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

When we terminate due to an exception being uncaught, libc++abi prints
a message saying "terminating with uncaught exception [...]". This patch
changes that to say "terminating due to uncaught exception [...]" instead,
which is a bit clearer. Indeed, I've seen some people being confused and
thinking that libc++abi was the component throwing the exception.

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

Mixed int/pointer min/max are no longer possible.

NFC.

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

Currently for SVE2 ACLE builtins, single tests are used to verify both
clang code generation (when the feature is available) and semantic
error/warning messages (when the feature is unavailable). This
patch moves the semantic testing for the target feature flag into
dedicated Sema tests.

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

Currently for SVE ACLE builtins, single tests are used to verify both
clang code generation (when the feature is available) and semantic
error/warning messages (when the feature is unavailable). This
patch moves the semantic testing into dedicated Sema tests.

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

Running on SemaDecl.cpp with the cxx.bnf grammar:

```
--------------------------------------------------------------
Benchmark                    Time             CPU   Iterations
--------------------------------------------------------------
runParseBNFGrammar      649389 ns       649365 ns         1013
runBuildLR            34591903 ns     34591380 ns           20
runPreprocessTokens   11418744 ns     11418703 ns           61 bytes_per_second=63.8971M/s
runGLRParse          282996863 ns    282988726 ns            2 bytes_per_second=2.57827M/s
runParseOverall      294969719 ns    294951870 ns            2 bytes_per_second=2.4737M/s
```

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

nuw does not make sense for reverse iteration.

This issue reproduces in the context of LoopDeletion, because the
bitcast does not get simplified away there. For a plain -inst-simplify
run the bitcast would get folded away first.

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

The EnableReuseStorageInFrame option is designed for testing only.
But it is better to use *_PASS_WITH_PARAMS macro to keep consistent with
other passes.

30a12f3f switched the type check
to use the GEP result type rather than the GEP operand type.
However, the GEP result types may match even if the operand types
don't, in case GEPs with scalar/vector base and vector index
are compared.

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

This patch make CodeGen/test/AArch64/vecreduce-add-legalization.ll fail.

This reverts commit 17a8a1bb.

Reviewed By: craig.topper

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

Reviewed By: frasercrmck

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

This halves the size of LargeTest, dropping time to compile this
file locally from 14s to 5.5s. Hopefully this will also fix the
persistent timeouts in pre-merge checks.

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

Building libMLIR.so currently fails with:

> /usr/bin/ld: /tmp/ccNzulEA.ltrans39.ltrans.o: in function `(anonymous namespace)::SerializeToHsacoPass::optimizeLlvm(llvm::Module&, llvm::TargetMachine&)':
> /builddir/build/BUILD/llvm-project-15.0.0.src/mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp:328: undefined reference to `mlir::makeOptimizingTransformer(unsigned int, unsigned int, llvm::TargetMachine*)'

This is because MLIRGPUTransforms depends on MLIRExecutionEngine in
https://github.com/llvm/llvm-project/blob/61bb2e4ea82fc5499a271d70d4537383d1942208/mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp#L328,
but MLIRExecutionEngine is marked as excluded from libMLIR.so.

However, this code doesn't require the full execution engine: It
only performs middle-end optimization, and does not need any of
the JIT/codegen infrastructure. As such, split off a separate
library MLIRExecutionEngineUtils, which only contains that part
and is not excluded from libMLIR.so.

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

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

This is to minimize superfluous assume calls.

Depends on D124758

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

Summary:
By evaluating both children states, now we are capable of discovering
infeasible parent states. In this patch, `assume` is implemented in the terms
of `assumeDuali`. This might be suboptimal (e.g. where there are adjacent
assume(true) and assume(false) calls, next patches addresses that). This patch
fixes a real CRASH.
Fixes https://github.com/llvm/llvm-project/issues/54272

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

In some cases a parent State is already infeasible, but we recognize
this only if an additonal constraint is added. This patch is the first
of a series to address this issue. In this patch `assumeDual` is changed
to clone the parent State but with an `Infeasible` flag set, and this
infeasible-parent is returned both for the true and false case. Then
when we add a new transition in the exploded graph and the destination
is marked as infeasible, the node will be a sink node.

Related bug:
https://github.com/llvm/llvm-project/issues/50883
Actually, this patch does not solve that bug in the solver, rather with
this patch we can handle the general parent-infeasible cases.

Next step would be to change the State API and require all checkers to
use the `assume*Dual` API and deprecate the simple `assume` calls.

Hopefully, the next patch will introduce `assumeInBoundDual` and will
solve the CRASH we have here:
https://github.com/llvm/llvm-project/issues/54272

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

While it originally did, this option no longer affects the cc1
interface. For the cc1 interface, -no-opaque-pointers has to be
passed, there is no cmake option.

The variable name checked didn't match the one set on the line above.

This error was introduced in b3df14b6.

Looks like this test exposes some non-determinism and fails with
auth-generated checks. Recommited with sole check it didn't crash.
Will investigate why it happens.

This reverts commit 1daf35f4.

Make sure "[SLP]Further improvement of the cost model for scalars used in buildvectors."
does not come back until it's fixed.

This reverts commit 9d2dd6d7.

Reverting because this exposes an issue in the uint64_t json parser.

This is a following cleanup for the previous work D123918. I missed
serveral places which still use legacy pass managers. This patch tries
to remove them.

This patch adds lowering for task construct from Fortran to
`omp.task` operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.

Reviewed By: kiranchandramohan, peixin

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

llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.

Even if the minimum number of elements is 1 and the length doesn't change,
we don't know what vscale is so we can't classify it as identity mask. Instead it
is a zero element splat.

For reverse, we shouldn't classify it as a reverse unless there are at least 2 elements
in the mask. This applies to both fixed and scalable vectors. For fixed vectors, a single
element would be an identity shuffle. For scalable vector it's a zero elt splat.

Reviewed By: sdesmalen, liaolucy

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

    It turns out that the issue in
    https://lab.llvm.org/buildbot/#/builders/17/builds/21754 is that a
    size_t is attempted to be used interchangeably with uint64_t.