Avoid use of no-op GEPs.

As far as I can see they are unnecessary and in C++20 they lead to errors.
Removing them the tests pass with C++20 and the default version.
Example error message:
```
llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:275:30: error: expected unqualified-id before ‘)’ token
  275 |   MockAnalysisHandle<Module>() { setDefaults(); }
```

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

The GreedyPatternRewriteDriver did previously not count the first iteration. I.e., when setting `config.maxIterations = 1`, two iterations were performed. In pratice, this number is not really important; we usually just need a limit in some reasonable order of magnitude. However, this fix allows us to write better convergence/worklist tests with carefully crafted test patterns to purposely trigger edge cases in the driver.

Similarly, the first rewrite was previously not counted towards `config.maxNumRewrites`.

For consistency, `OpPatternRewriteDriver` now uses `config.maxNumRewrites` instead of `config.maxIterations`; this driver does not have "iterations", it consists of a single loop (corresponding to the inner loop in the GreedyPatternRewriteDriver).

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

Reapply with checks for instructions in unreachable blocks. A test
case for this was added in 1ee4a93b.

-----

This is a recurring pattern: We want to find the nearest common
dominator (instruction) for two instructions, but currently only
provide an API for the nearest common dominator of two basic blocks.

Add an overload that accepts and return instructions.

This only effects folks building with wasm64 + shared memory which
is not currently a supported configuration in emscripten or any other
wasm toolchain.

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

wasm32 was already supported, so here I've just reused the same regex. I'm not sure if this is actually correct: I don't know for certain if wasm32 and wasm64 have different output formats, but it seems to work.

Reviewed By: dschuff, asb

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

This reverts commit 957952db.

Addition in the newly added code can overflow.  As a result, the
constructor of `BranchProbability()` can trigger an assertion. See
the discussion on https://reviews.llvm.org/D138132 for more details.

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

Simplifies diff for D141363

When the latch block is different from header block, IVInc will be expanded in the latch loop. We can't generate the post index load/store this case.
But if the IVInc only used in the loop, actually we still can use the post index load/store because when exit loop we don't care the last IVInc value.
So, trying to hoist IVInc to help backend to generate more post index load/store.

Fix #53625

Reviewed By: eopXD

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

This commit adds function `vlenb` into riscv_vector.h. `vlenb` is defined
through builtin function `__builtin_rvv_vlenb`, which is lowered to
`llvm.read_register`.

Reviewed By: kito-cheng, pcwang-thead

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

This test is testing whether the compiler behaves correctly when only
parts of an operand are masked.
In this case, no optimization is supposed to happen, since neither
the upper nor the lower half is
fully masked. Therefore, none
of the halves can be known to be zero.
The result is a regular multiplication.

This reverts commit a28f0747.

It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.

Reviewed By: aykevl, Miss_Grape

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

Tries to perform
  (lshr (add (zext X), (zext Y)), K)
  ->  (icmp ult (add X, Y), X)
  where
    - The add's operands are zexts from a K-bits integer to a bigger type.
    - The add is only used by the shr, or by iK (or narrower) truncates.
    - The lshr type has more than 2 bits (other types are boolean math).
    - K > 1

This seems to be a pattern that just comes from OpenCL front-ends, so adding DAG/GISel combines doesn't seem to be worth the complexity.

Original patch D107552 by @abinavpp - adapted to use (a + b < a) instead of uaddo following discussion on the review.
See this issue https://github.com/RadeonOpenCompute/ROCm/issues/488

Reviewed By: spatel

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

Move the code to lower an expression to address or a box in HLFIR from
Bridge.cpp to ConvertExpr.cpp so that it can be used inside
ConvertVariable.cpp (that needs to use a different symbol map that the
one held in the bridge).

Lower NULL to hlfir.null.

This allows lowering derived type constant structure constructors with
pointer components into fir.global.

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

Separate commit for D138814's testcases to make review easier.

Reviewed By: spatel

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

The current lowering of initial target in fir.global is relying
on how fir.box are created: instead of using a fir.rebox to add
the POINTER attribute to the created descriptor, it is looking
for a fir.embox defining operation and creating a copy of
it with a different result types.

The rational for doing so was that fir.rebox codegen was not possible
inside fir.global because it expects to manipulate the input fir.box
in memory, while objects cannot be manipulated in memory inside
a fir.global region that must be constant foldable.

But this approach has two problems:
- it won't work with hlfir where fir.box may be created by more
  operations than fir.embox (e.g. hlfir.delcare or hlfir.designate).
  In general, looking for a precise defining op for a value is
  fragile.
- manually copying and modifying an operation is risky: it is easy
  to forget copying some default operands (that could be added later).

This patch modifies the helpers to get descriptor fields so that they
can both operate on fir.box lowered in memory or in an llvm.struct
value. This enables the usage of fir.rebox in fir.global op.

The fallout in FIR tests is caused by the usage of constant index
when creating GEP (because extractOp requires constant indices).
MLIR builder uses i32 bit constant indices when non mlir::Value
indices are passed to the MLIR GEP op builder. Previously,
an 64 nist mlir constant value was created and passed to the GEP
builder. In this case, the builder respect the value type when
later generating the GEP.
Given this changes impact the "dimension" index that can, per
Fortran requirement, not be greated than 15, using a 32 bit index
is just fine and actually simplify the MLIR LLVM IR generation.

The fallout in lowering tests is caused by the introduction
of the fir.rebox everytime an initial target is created.

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

This reverts commit 5b72d0e4.

The test added is failing on Mac/Windows. See review for buildbot failure links.

This reverts commit 9f4a9d3f.

Reverting this change which was a follow-up to 5b72d0e4 which is being reverted due to test failures on Mac/Windows.

Summary: This patch handles relocation field overflows in an XCOFF32 file. (XCOFF64 files may not have overflow section headers.) If a section has more than 65,534 relocation entries or line number entries, both of these fields are set to a value of 65535. In this case, an overflow section header with the s_flags field equal to STYP_OVRFLO is used to contain the relocation and line-number count information. Since line number is not supported, this patch only handles the relocation overflow.

Reviewed By: shchenz

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

When we see a store in generic mode we need to decide if we should guard
it for SPMDzation. This patch changes the getUnderlyingObjects call to
the more optimistic getAssumedUnderlyingObjects call to identify more
thread local pointers.

If LLVM_BUILTIN_TARGETS is not set, no OS specific variants will be
created, causing CMake build failure. Depend on the generic builtins
target if LLVM_BUILTIN_TARGETS is not set.

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

Remove globals from the lldCOFF library, by moving globals into a context class.
This patch mostly moves the config object into COFFLinkerContext.

See https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html for
context about removing globals from LLD.

Reviewed By: aganea

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

This reverts commit 54d78b63.

This reverts commit 97178625.

This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.

As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.

Reviewed By: majnemer

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

Conditions for dominating branches and llvm.assumes are already
collected. This also adds conditions from guards.

Reviewed By: nikic

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

Using the option `-print-sorted-by=.` cause to core dump, so change to a legal value.

Reviewed By: maksfb

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

See https://reviews.llvm.org/D140867.

The signature of the constructor/destrucor of the global variables is
different in different targets. And the CHECKs in the test is
unavailable in other targets (e.g., AIX). So the patch tries to avoid
the test failure by requiring the target type.

This reverts commit 1f1d5018.

This patch caused several sanitizer tests failed. Revert it to unblock
others.

This patch adds codegen support for XTHeadVdot extension,
which is documented here, it's based on standard vector extension v1.0:
  https://github.com/T-head-Semi/thead-extension-spec

Reviewed By: craig.topper

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

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

Reviewed By: Mogball

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