This is permitted by the op, but the current lowering generates invalid IR.

Reviewed By: springerm

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

Adds intrinsics for the following SME2 instructions:
 - smlall (1, 2 & 4 vectors)
 - umlall (1, 2 & 4 vectors)
 - smlsll (1, 2 & 4 vectors)
 - umlsll (1, 2 & 4 vectors)
 - sumlall (2 & 4 vectors)
 - usmlall (1, 2 & 4 vectors)

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

Reviewed By: david-arm

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

Current code are crashing on the assert `assert(seqTy && "must be an array");`.

Add a TODO instead until the support is in.

Reviewed By: jeanPerier

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

The `basic_string_view` constructor accepting a contiguous range rejects
converting between `basic_string_view` even when only the trait types vary.
This prevents conversions for converting from `basic_string_view<C, T1>` and
`basic_string<C, T1, A>` to `basic_string_view<C, T2>`.  Recently, this
constructor was made `explicit`, so there's no reason to really forbid this
conversion anymore.

Relax the restriction that the trait types need to match in this constructor.

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

Reviewed By: cor3ntin

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

We are about to allow different trace strategies for MachineCombiner. Make
the name of the ensemble strategy-neutral.

Depends on D140540

Reviewed By: spatel

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

The code only needs access to INvalidCosts, ORE and TheLoop, so it can
easily be moved into a helper to make selectVectorizationFactor more
compact.

Reviewed By: sdesmalen

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

This commit renames the "di_void_result_type" to "di_null_type" as LLVM
does use null not exclusively for void types. An added test demonstrates
this for variadic function declarations, whose DISubroutine indicates the
start of variadic types with `null`.

Reviewed By: gysit

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

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

Reviewed By: psoni2628, raghavendhra

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

Although specifying an index that is out of bounds for both `memref.dim`
and `tensor.dim` produces an undefined behavior, this is still valid IR.
In particular, we could expose an out of bound index because of some
optimizations, for instance as demonstrated with
https://github.com/llvm/llvm-project/issues/60295, and this shouldn't
cause the compiler to abort.

This patch removes the overzealous verifier checks and properly handles
out of bound indices (as in it doesn't crash the compiler, but still
produces UB).

This fixes https://github.com/llvm/llvm-project/issues/60295.

Note: That `shape.dim` has a similar problem but we're not supposed to
produce UB in this case. Instead we're supposed to propagate an error in
the resulting value and I don't know how to do that at the moment. Hence I
left this part out of the patch.

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

llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.

The code has been divided into the following patches:

1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
8a) Memory Management
9) CodeView Reader

Full details:

https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570

This patch:

This is a high level summary of the changes in this patch.

Memory Management
- Use Bump allocators for memory management.

As the logical elements are only allocated in one pass (debuginfo
parsing) and they are never manipulated/created/destroyed later,
use the SpecificBumpPtrAllocator for the memory management.

Reviewed By: dblaikie, Orlando

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

Our bot has been failing https://lab.llvm.org/buildbot/#/builders/178/builds/3967:
Assertion `isecEnd - isecVA <= forwardBranchRange && "should only finalize sections in jump range"' failed.

I think this is due to the use of size_t, which is 32 bit on 32 bit,
for a value used in some 64 bit address calculations. Which was added in
https://reviews.llvm.org/D144029.

Switching to uint64_t fixes the issues.

Check upfront whether the load is based on a constant global
with definitive initializer. Don't bother computing offsets
otherwise.

Add a test to check that the template instantiation during the template
specialization wouldn't be emitted again in the importer.

Currently, JT creates and updates local instances of BPI\BFI. As a result global ones have to be invalidated if JT made any changes.
In fact, JT doesn't use any information from BPI/BFI for the sake of the transformation itself. It only creates BPI/BFI to keep them up to date. But since it updates local copies (besides cases when it updates profile metadata) it just waste of time.

Current patch is a rework of D124439. D124439 makes one step and replaces local copies with global ones retrieved through AnalysisPassManager. Here we do one more step and don't create BPI/BFI if the only reason of creation is to keep BPI/BFI up to date. Overall logic is the following. If there is cached BPI/BFI then update it along the transformations. If there is no existing BPI/BFI, then create it only if it is required to update profile metadata.

Please note if BPI/BFI exists on exit from JT (either cached or created) it is always up to date and no reason to invalidate it.

Reviewed By: mkazantsev

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

One test for checking the decls in language linkage shouldn't be
discarded and can be mangled correctly.

Another one for checking we can't export again in an export decl.

The revision adds support for importing alias.scope and noalias metadata
from LLVM IR into LLVM dialect. It also adds a verifier to the
AliasScopeMetadataOp to check that the associated domain exists
and is of type AliasScopeDomainMetadataOp.

Reviewed By: Dinistro

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

InstCombine is supposed to be a superset of InstSimplify, but we
were not attempting simplification of insertvalue instructions.
As the test change illustrates, we failed to remove some aggregate
construction patterns because of that.

This is like test2 from the same file, but using poison instead of
undef as base, which matches the IR we use nowadays.

We can only fold insertvalue undef, (extractvalue x, n) to x
if x is not poison, otherwise we might be replacing undef with
poison (https://alive2.llvm.org/ce/z/fnw3c8). The insertvalue
poison case is always fine.

I didn't go to particularly large effort to preserve cases where
folding with undef is still legal (mainly when there is a chain of
multiple inserts that end up covering the whole aggregate),
because this shouldn't really occur in practice: We should always
be generating the insertvalue poison form when constructing
aggregates nowadays.

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

Scope to retrieve the associating entity is needed to map the
symbol to the IR value. The scope can be found with a source
information. For the type case in SELECT TYPE construct, the source
information is on the Statement<TypeCase>. This patch updates
the lowering so the scopes for each type guards is retrieved
before the processing.

Reviewed By: PeteSteinfeld, vdonaldson

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

Because we are generating uninitialized value for no integer type and use `isUninitialized()` to judge if it is valid after https://reviews.llvm.org/rG93f081c896536112e1ca8133991d23cb1134793a, we should check the value before use `getValue` to get it.
Fixes https://github.com/llvm/llvm-project/issues/59984.

Reviewed By: Mogball

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

Following recent changes to remove non-core legacy passes.

Some codes become unused after we remove ModulesTS.

As the diagnostic message shows, we should remove -fmodules-ts flag in
clang/llvm17. Since clang/llvm16 is already branched. We can remove the
depreacared flag now.

Reviewed By: LuoYuanke
Differential Revision: https://reviews.llvm.org/D144163

This patch replaces isPowerOf2_32 with llvm::has_single_bit<uint32_t>
where the argument is wider than uint32_t.

This patch replaces rotate with llvm::rotate<uint64_t> where the
rotate count is an immediate.

We're going to remove the support for modules-ts. But there are a lot of
tests which uses -fmodules-ts. We shouldn't remove them simply. This
patch refactor these tests to use standard c++ modules.

Referencing the corresponding change from the source of the test cases:
riscv-non-isa/rvv-intrinsic-doc#196

Reviewed By: craig.topper

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

Plain `getVectorType()` can be quite confusing and error-prone
given that, well, vector ops always work on vector types, and
it can commonly involve both source and result vectors. So this
commit makes various such accessor methods to be explicit w.r.t.
source or result vectors.

Reviewed By: ThomasRaoux

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

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This function doesn't use any members from the class so it can be
static.