BatchClass is used to manage the free blocks for each size class. It's a
little bit tricky when it has to manage the free blocks of BatchClass.
In general, BatchClass block records the addresses of free blocks. In
order not to waste additional block to record the blocks in BatchClass,
it's self contained, i.e., it'll record its own address. The safety is
maintained by 2 preconditions,

  1. If a block is used to record other BatchClass blocks, it'll also
     record the address itself
  2. While allocating free blocks, all the recorded blcoks will be
     allocated together, which means there's no partial allocation

This CL fixes the violation of 1. and then we can push the free blocks
without having to push them in batches.

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

This class wraps a `SymbolTableCollection` to allow shared access to the
collection of symbol tables (but not the individual symbol tables). This
can be used, for example, in a pass that shards work among symbols that
requires symbol lookups.

Reviewed By: rriddle

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

Fixes #60911

Reviewed By: psoni2628

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

Makes it easier for the switch to be extended in the future.

Up to C++20, hasDefaultConstructor and !hasNonTrivialDefaultConstructor together implied
hasTrivialDefaultConstructor. In C++20, a constructor might be ineligible and can set
hasDefaultConstructor without setting hasNonTrivialDefaultConstructor.

Fix this by querying hasTrivialDefaultConstructor instead of hasDefaultConstructor.

I'd like to backport this to Clang 16.
I only change isTrivialType and in a way that should only affect code that uses
constrained constructors, so I think this is relatively safe to backport.

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

Reviewed By: aaron.ballman

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

I recently came across a binary that for some reason had overlapping
sections. When debugging it, LLDB was able to get information about one
of the sections but not the other because SectionLoadList assumes that
each address maps to exactly one section. We have the capability to warn
about this, but it was not turned on.

rdar://105751700

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

Instead of replacing "F16", "F32", "F64" anywhere in the string.
Only replace them when proceeded by a "_", "_V", or "_W".

This allows F16/F32/F64 to appear in the instruction name.
This is needed for some vendor instructions in our downstream. We
may be upstreaming them in the future.

Reviewed By: craig.topper, MaskRay

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

Reviewed By: aartbik

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

Last part of https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

All active users that I am aware of have already switched. Any remaining users will be forced to adopt their code after this patch has landed.

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

Simplify `MCPlusBuilder::evaluateX86MemoryOperand`: make it return a struct
with memory operand analysis struct `X86MemOperand`.

Reviewed By: #bolt, rafauler

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

Create writer for new JSON format.
The new JSON format allows practically all attributes to be defined per
target in a universal library however the internal representation only
allows one for the time being. For now the write will always write those
attributes as default available for all targets (install name,
compatability & current version, swift abi, flags e.g. flatnamepace &
app exenstion safety)

rdar://102076911

Reviewed By: ributzka

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

The generalization pattern for tensor.pack was inverting the
innerDimsPos permutation when normalizing. Thus, the transpose op
produced by the generalization would be incorrect.

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

Reviewed By: vitalybuka

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

This reverts commit 8217932a.

Breaks buildbots.

Create writer for new JSON format.
The new JSON format allows practically all attributes to be defined per
target in a universal library however the internal representation only
allows one for the time being. For now the write will always write those
attributes as default available for all targets (install name,
compatability & current version, swift abi, flags e.g. flatnamepace &
app exenstion safety)

rdar://102076911

Reviewed By: ributzka

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

This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.

The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.

Reviewed By: labath

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

This patch implements vectorization of tensor.extract for n-D tensor (n
>= 2) using contiguous load operations, i.e. `vector.transfer_read`. This
is a follow-up of https://reviews.llvm.org/D137660 in which gather loads
were used, i.e. `vector.gather`.

It is always safe to use gather load operations when the underlying
memory pattern is contiguous, but not vice-verse. At the moment, the
following conditions have to be met for contiguous loads to be
generated:
  1. The _output tensor_ must be a 1-D vector with the trailing dim > 1,
     e.g. `tensor<1x1x4xi32`,
  2. The trailing dim in the _input tensor_ must be > 1, e.g.
     `tensor<1x1x4i32>` would be fine, but not `tensor<1x4x1xi32>`.
If these conditions are not satisfied, gather loads are generated
instead.

Condition 1 guarantees that the iteration space of the corresponding
`linalg.generic` Op is relatively simple. That makes analysing the
indices for `tensor.extract` rather straightforward.

Condition 2 is mostly there to avoid weird vectorisation patterns
resulting in vectors like: `vector<1x1x1xi32>`. In practice, tensors
like `tensor<1x4x1xi32>` should be collapsed to `tensor<1x4xi32>` before
vectorisation, but that's beyond the scope of this patch.

If needed, both conditions can be relaxed. I've not been able to find a
good motivating example for these, hence skipping. For reference,
`tosa.resize` (lowered to Linalg) was the driving example used here.

As a bonus, the test from "vectorization-unsupported.mlir" is moved to
"vectorization.mlir" with proper CHECK lines added.

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



Co-authored-by: Diego Caballero <diegocaballero@google.com>

This patch adds a partial implementation of `quick_exit` for the GPU
target. This is mainly done to test object libraries for the GPU and
will be expanded later. This will simply cause the threads to terminate
on the GPU without returning an error code. This functionality will be
added later to facilitate unit tests.

Reviewed By: sivachandra

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

A single class allows multiple categories to be defined for it. But if
two of such categories have the same name, we emit a warning. It's not a
hard error but a good indication of a potential mistake.

With modules, we can end up with the same category in different modules.
Diagnosing such a situation has little value as the categories in
different modules are equivalent and don't reflect the usage of the same
name for different purposes. When we deserialize a duplicate category,
compare it to an existing one and warn only when the new one is
different.

rdar://104582081

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

65420c80 introduced an ICE in combineMinNumMaxNum(...) when
combineMinNumMaxNumImpl(...) returns an SDValue(). Make sure to check that a
value is returned before trying to perform an FNEG on it.

GitHub Issue: #60924

Reviewed By: arsenm

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

A mistake in the control flow of performMemPairCombine resulted in paired
loads/stores for types that were not supported by the instructions (i8/i16).
These loads/stores could not match the constraints of the patterns defined
in the THead td file and the compiler would throw a 'Cannot select' error.

This is now fixed and two new test functions have been added in xtheadmempair.ll
which would previously crash the compiler. The compiler was additionally tested
with a wide range of benchmarks and no issues were observed.

Reviewed By: craig.topper

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

Per spec:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/ntohl.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/ntohs.html



Co-authored-by: Jeff Bailey <jbailey@google.com>

Reviewed By: sivachandra

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

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

Not entirely sure we'll end up reusing the body of the transform, but personally I find this structure easier to follow anyways.

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

This reverts commit 451799bb.

Causes crashes, see D139209

Summary:
Currently AMDGPU only barely supports cross-TU ELF linking. Full linking
is usually done via LTO. This requires passing the architecture to the
link job. This is done automatically via `-flto` since D144505. Add this
to the link options.

This reverts commit efae3174 since
it broke the standalone Flang build.

[AMDGPU] Improve the lowering of raw_buffer_load_{i8,i16} and struct_buffer_load_{i8,i16} intrinsics

Currently, raw_buffer_load_{i8,i16} and struct_buffer_load_{i8,i16}
intrinsics are lowered as buffer_load_{u8,u16}. This patch combines
buffer_load_{u8,u16} and sign extension instructions in order to
generate buffer_load_{i8,i16} instructions.

Reviewed By: foad

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

The module flag "debug-info-assignment-tracking" is set by the
declare-to-assign pass to indicate that assignment tracking is enabled. This
patch changes declare-to-assign to only set the flag if it makes a
modification. This lets the compiler avoid doing extra work for no benefit,
such as is currently the case if assignment tracking is requested for a build
with line tables only (-gmlt) or a build without debug info.

Reviewed By: scott.linder

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

v_permlane16_b32 and v_permlanex16_b32 should not set abs and neg src
modifiers on any input, but they can set op_sel on src0 or src1 to
represent fi or bc when desired. The ISel patterns were setting
the src_modifier bits to -1, effectively setting abs and neg as well,
whenever it was intended to set op_sel, due to an error in ISel. ISel
should now correctly only set the op_sel bits.

Reviewed By: arsenm

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

Enabling assignment tracking without this patch, a significant amount of
additional compiler run time comes from the RemoveRedundantDbgInstrs call in
InstCombine. This patch reduces compiler run time by choosing better places to
call RemoveRedundantDbgInstrs.

In non-assignment-tracking builds, RemoveRedundantDbgInstrs is called by
InstCombine if LowerDbgDeclare makes a change (i.e. it is _sometimes_
called). In assignment tracking builds LowerDbgDeclare doesn't do anything. We
still need to clean up redundant intrinsics to avoid a large performance hit
due to the number of instructions, so the current approach is to have
InstCombine _always_ call RemoveRedundantDbgInstrs.

Instrumenting the compiler to run RemoveRedundantDbgInstrs after every pass and
dump the numbers and building CTMark/tramp3d-v4 indicates that SROA and
LoopVectorize give us a bigger bang (number removed) for buck (times pass is
run).

The compile time tracker reports that this patch reduces the number of
instructions retired building CTMark projects by an average of 1.1%.

Reviewed By: scott.linder

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

Moving this out of AMDGPUBaseInfo enforces that AMDGPUBaseInfo should
not be calling into GCNSubtarget.

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

Reviewed By: #libc, philnik

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

After reading about the documentation improvements on LLVM weekly this
part seems obsolete.

Reviewed By: ChuanqiXu

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

The AMDGPU toolchain support directly compiling GPU images using
cross-compilation such as `clang --target=amdgcn-amd-amdhsa foo.c`.
However, when attempting to link bitcode this does not work because the
`-mcpu` options are not forwarded to the linker among others. This patch
simply adds them so that `clang --target=amdgcn-amd-amdhsa foo.c -flto`
works correctly.

Reviewed By: JonChesterfield

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

These shouldn't really reach SCEV without being folded away first,
and we don't have any tests that hit these cases.

The sizeof case does occur with scalable types.