Revert rG6aa7cc03 - "[X86] LowerVectorAllZero - add 512-bit support with AVX512 vptestnmd+kortestw patterns"

Reverted - I need to adjust the implementation so we can properly refactor it into a "LowerVectorAllEqual" function

Commit cc2457ca changed the default but forgot to update the help message.

Implement MC support for the recently ratified RV64E base instruction
set.

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

Another step toward #53419 - this is also another step towards expanding MatchVectorAllZeroTest to match any pair of vectors and merge EmitAVX512Test into it.

Private headers inside umbrella files shouldn't be marked as unused.

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

This reverts commit 201fdef4.

There was an issue found in post-commit by:
https://lab.llvm.org/buildbot/#/builders/91/builds/15272

NFC

It doesn't make sense on ARM and using default 0 fill is compatible
with MSVC.

(It's more noticeable ARM64EC targets, where additional padding mixed
with alignment is used for entry thunk association, so there are more
gaps).

Reviewed By: mstorsjo

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

We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section that does not really fit GNU format.
This patch implements writing in COFF format (as in, it's what archive
reader considers as K_COFF). This mostly requires symbol emitting symbol
map. Note that, just like in case of MSVC, symbols are de-duplicated in
both usual symbol table and the new symbol map.

Reviewed By: efriedma

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

Having string table in members vector does not fit later patches in
this series. Symbol map needs to refer to objects' offsets, but string
table should not be referenced. Also for ARM64EC, the new <ECSYMBOLS>
table is inserted after string table.

Reviewed By: efriedma

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

In preparation for COFF archives support.

Reviewed By: efriedma

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

Since D141386 has changed the return value of !range from IUB to poison,
metadata !range shouldn't be preserved even if K dominates J.

If this patch was accepted, I plan to adjust metadata !nonnull as well.
BTW, I found that metadata !noundef is not handled in combineMetadata,
is this intentional?

Reviewed By: nikic

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

The patch had missed the RISCVISAInfoTest.cpp change.

These patterns follow FoldMemRefAliasOps which is further refactored for reuse.
In the process, fix FoldMemRefAliasOps handling of strides for vector.transfer ops which was previously incorrect.

These opt-in patterns generalize the existing canonicalizations on vector.transfer ops.
In the future the blanket canonicalizations will be retired.
They are kept for now to minimize porting disruptions.

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

Extend the existing MainFileMacros structure:
- record more information (InConditionalDirective) in MacroOccurrence
- collect macro references inside macro body (fix a long-time FIXME)

So that the MainFileMacros preseve enough information, which allows a
just-in-time convertion to interop with include-cleaner::Macro for
include-cleaer features.

See the context in https://reviews.llvm.org/D146017.

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

The goal is to be able to understand how the analysis executes, and what its
incremental and final findings are, by enabling logging and reading the logs.
This should include both framework and analysis-specific information.

Ad-hoc printf-debugging doesn't seem sufficient for my understanding, at least.
Being able to check in logging, turn it on in a production binary, and quickly
find particular analysis steps within complex functions seem important.

This can be enabled programmatically through DataflowAnalysisOptions, or
via the flag -dataflow-log. (Works in unittests, clang-tidy, standalone
tools...)

Important missing pieces here:
 - a logger implementation that produces an interactive report (HTML file)
   which can be navigated via timeline/code/CFG.
   (I think the Logger interface is sufficient for this, but need to prototype).
 - display of the application-specific lattice
 - more useful display for the built-in environment
   (e.g. meaningful & consistent names for values, hiding redundant variables in
   the flow condition, hiding unreachable expressions)

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

After some discussion and experimentation, we have seen that changing the default number of vector register bits to LMUL=2 strikes a sweet spot.
Whilst we could be clever here and make the vectorizer smarter about dynamically selecting an LMUL that
a) Doesn't affect register pressure
b) Suitable for the microarchitecture
we would need to teach its heuristics about RISC-V register grouping specifics.
Instead this just does the easy, pragmatic thing by changing the default to a safe value that doesn't affect register pressure signifcantly[1], but should increase throughput and unlock more interleaving.

[1] Register spilling when compiling sqlite at various levels of `-riscv-v-register-bit-width-lmul`:

LMUL=1    2573 spills
LMUL=2    2583 spills
LMUL=4    2819 spills
LMUL=8    3256 spills

Reviewed By: craig.topper

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

The old implementation parsed the optional attribute dict, only to replace its
contents by using `assign`.

Reviewed By: ftynse

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

This first version lays the foundations for AArch32 support in JITLink. ELFLinkGraphBuilder_aarch32 processes REL-type relocations and populates LinkGraphs from ELF object files for both big- and little-endian systems. The ArmCfg member controls subarchitecture-specific details throughout the linking process (i.e. it's passed to ELFJITLinker_aarch32).

Relocation types follow the ABI documentation's division into classes: Data (endian-sensitive), Arm (32-bit little-endian) and Thumb (2x 16-bit little-endian, "Thumb32" in the docs). The implementation of instruction encoding/decoding for relocation resolution is implemented symmetrically and is testable in isolation (see AArch32 category in JITLinkTests).

Callable Thumb functions are marked with a ThumbSymbol target-flag and stored in the LinkGraph with their real addresses. The thumb-bit is added back in when the owning JITDylib requests the address for such a symbol.

The StubsManager can generate (absolute) Thumb-state stubs for branch range extensions on v7+ targets. Proper GOT/PLT handling is not yet implemented.

This patch is based on the backend implementation in ez-clang and has just enough functionality to model the infrastructure and link a Thumb function `main()` that calls `printf()` to dump "Hello Arm!" on Armv7a. It was tested on Raspberry Pi with 32-bit Raspbian OS.

Reviewed By: lhames

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

RV32E was recently [ratified](https://github.com/riscv/riscv-isa-manual/commit/afd613691cb89ccd7584206e8a6d1866fe77ec88) so we should update the version as our MC-layer support is complete.

Reviewed By: kito-cheng

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

The deleted copy constructor LLVMContext(LLVMContext &) got its
parameter changed to const to allow the latest clang compiler to
instantiatiate template std::optional<LLVMContext>.

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

This reverts commit 7a5b9573.

Regenerate the style documentation, requires some minor sphinx changes to avoid warnings

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

Fixes #61607

Several names were repeated in this giant list. I have refactored
it and removed the duplicates.

Reviewed By: dmgreen

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

This reverts commit 0691bcb1.

Looks like this breaks builders, e.g.
https://lab.llvm.org/buildbot#builders/231/builds/9790

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

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

Summary: A R_REF relocation as a non-relocating reference is required to prevent garbage collection (by the binder) of the ref symbol in object generation.

Reviewed By: shchenz

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

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

`BoundType` is no longer a nested member of `IntegerRelation` but a top-level enum in the `presburger` namespace.

This allows `BoundType` to be predeclared in header files. Nested members cannot be predeclared.

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

Fix bug and MSAN issue in affine loop utils introduced by
d25e022c (D146495). While on it,
fix/clean up issues in immediately surrounding code.

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

The new class hierarchy is as follows:

* `IntegerRelation` (no change)
* `IntegerPolyhedron` (no change)
* `FlatLinearConstraints`: provides an AffineExpr-based API
* `FlatLinearValueConstraints`: stores an additional mapping of non-local vars to SSA values
* `FlatAffineValueConstraints`: provides additional helper functions for Affine dialect ops
* `FlatAffineRelation` (no change)

`FlatConstraints` and `FlatValueConstraints` are moved from `MLIRAffineAnalysis` to `MLIRAnalysis` and can be used without depending on the Affine dialect.

This change is in preparation of D145681, which adds an MLIR interface that depends on `FlatConstraints` (and cannot depend on the Affine dialect or any other dialect).

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

Test suite name can also be disabled with DISABLED_, not just
the test case name.

Fix also broken link in the test that refers to the explanation
as to why underscores may not be used.

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

The crash happened because the transfer fucntion for `&&` and `||`
unconditionally tried to retrieve the value of the RHS. However, if the RHS
is unreachable, there is no environment for it, and trying to retrieve the
operand's value causes an assertion failure.

See also the comments in the code for further details.

Reviewed By: xazax.hun, ymandel, sgatev, gribozavr2

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