We have several situations where it's beneficial for code size to ensure that every
call to always-inline functions are inlined before normal inlining decisions are
made. While the normal inliner runs in a "MandatoryOnly" mode to try to do this,
it only does it on a per-SCC basis, rather than the whole module. Ensuring that
all mandatory inlinings are done before any heuristic based decisions are made
just makes sense.

Despite being referred to the "legacy" AlwaysInliner pass, it's already necessary
for -O0 because the CGSCC inliner is too expensive in compile time to run at -O0.

This also fixes an exponential compile time blow up in
https://github.com/llvm/llvm-project/issues/59126

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

The buffer-deallocation pass generates a different output on each run
due to an unstable iteration order.

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

Reviewed By: mehdi_amini

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

The one caller of this function already checked that V isn't a
Constant.

Alternatively, we could remove the check from the caller if reviewers
prefer.

Reviewed By: spatel

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

Turns out there's a switch on APFloat semantics in clang I wasn't
aware of, fix the build error here.

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

Remove a special-case in clangd.

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

This isn't strictly needed, but this matches how MSVC lib.exe writes to
archives, so this makes llvm-lib more compatible and simplifies comparing
output between tools.

Reviewed By: hans

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

Reviewed By: peter.smith

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

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

AMD, GraphCore, and Qualcom have published a standard for 8-bit floats that
differs from the 8-bit floats defined by Nvidia, Intel, and ARM. This
commit adds support for these alternate 8-bit floats to APFloat in
order to enable their usage in MLIR. These formats are presented in
the paper at https://arxiv.org/abs/2206.02915 and are implemented in
GRaphCore hardware whose ISA is available at
https://docs.graphcore.ai/projects/isa-mk2-with-fp8/en/latest/_static/TileVertexISA-IPU21-1.3.1.pdf .

In these formats, like the existing Float8E4M3FN, there are no
infinity values and there is only one NaN. Unlike in that format,
however, the NaN values is 0x80, which would be negative 0 in IEEE
formats. This means that these formats also make 0 unsigned.

To allow for these new variant semantics, this commit adds
fltNanEncoding, which can be IEEE (the default), AllOnes (used by
Fleat8E4M3FN), or NegativeZero (used by the new formats,
Float8E5M2FNUZ and Float8E4M3FNUZ). Normalization, arithmetic, and
other such routines have been updated to account for the potential
variant semantics.

The two new formats are Float8E5M2FNUZ (5 bits exponent, 2 bits
mantissa, finite, unsigned zero) and Float8E4M3FNUZ (4 bits exponent,
3 bits mantissa, finite, unsigned zero).

Reviewed By: jakeh-gc, reedwm, lattner

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

Previously the type description structs were defined in the parser. For
the fuzzing targets we'll need to use those, so I've moved them into
core_structs.h. Additionally I've renamed the function for determining
the TypeDesc from a given type. Previously it shared its name with
get_type_desc which is a related but separate function that is a part of
the parser.

Reviewed By: lntue

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

Address space casts are present in common MLIR targets (LLVM, SPIRV).
Some planned rewrites (such as one of the potential fixes to the fact
that the AMDGPU backend requires alloca() to live in address space 5 /
the GPU private memory space) may require such casts to be inserted
into MLIR code, where those address spaces could be represented by
arbitrary memory space attributes.

Therefore, we define memref.memory_space_cast and its lowerings.

Depends on D141293

Reviewed By: ftynse

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

Fixes #60576.

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

Fix a typo and improve comments to match the LLVM coding style.

Add the ability to remove diagnostic callbacks. This is necessary for
diagnostics who's lifetime is tied to objects that can be destroyed.

Differential revision: https://reviews.llvm.org/D143548

This is just for consistency with FLAT_Global_Atomic_Pseudo.

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

Reviewed By: Peiming

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

Reviewed By: vitalybuka

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

Reviewed By: springerm

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

This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension. Selecting the proposed mapping turns out to be an involved conversation that really didn't fit within a review description, so let me refer you to https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst. This review implements the WMO compatible variant (the proposed one in that document).

Ztso is currently accepted as an experimental extension in LLVM. Despite the fact the extension was recently ratified, I think we need to leave it as experimental until we have wide agreement on the chosen mapping for ABI purposes.

I need to note that the current in-tree implementation defaults to generating WMO compatible fences. This is entirely compatible with the proposed mapping in this patch, but is unfortunately not compatible with the major alternative. The in tree implementation is explicitly experimental so the impact of this is limited, but it is worth calling out that if settle on the alternative we will have a minor ABI break. My apologies for not calling this out in the original patch; I had not realized at the time that one of our realistic choices for mappings wouldn't be WMO compatible.

This patch only contains the changes for load/store and fence. That is, it does not change the lowering for atomicrmw operations. This is a sound thing to do under the proposed mapping since the existing WMO mappings remain compatible. I do plan to change these; I'm just working incrementally.

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

This patch provides a simplified version of the Any intrinsic as well as the All intrinsic
that can be used for inlining or simpiler use cases. These changes are targeting exchange2, and
provide a ~9% performance increase.

Reviewed By: Leporacanthicus, vzakhari

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

LexedFileChanged has the semantics we want of ignoring #line/etc. It's
also consistent with other dep collectors like DependencyFileGenerator.

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

The motivation behind this patch is to unify some of the outliner logic across architectures. This looks nicer in general and makes fixing [issues like this](https://reviews.llvm.org/D124707#3483805) easier.
There are some notable changes here:
    1. `isMetaInstruction()` is used directly instead of checking for specific meta-instructions like `IMPLICIT_DEF` or `KILL`. This was already done in the RISC-V implementation, but other architectures still did hardcoded checks.
        - As an exception to this, CFI instructions are explicitly delegated to the target because RISC-V has different handling for those.

    2. `isTargetIndex()` checks are replaced with an assert; none of the architectures supported actually use `MO_TargetIndex` at this point in time.

    3. `isCFIIndex()` and `isFI()` checks are also replaced with asserts, since these operands should not exist in [any context](https://reviews.llvm.org/D122635#3447214) at this stage in the pipeline.

Reviewed by: paquette

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

Result must carry the polymorphic type information from the mold.

Reviewed By: jeanPerier

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

The code for unranked memref descriptors assumed that
sizeof(!llvm.ptr) == lizeof(!llvm.ptr<N>) for all address spaces N.
This is not always true (ex. the AMDGPU compiler backend has
sizeof(!llvm.ptr) = 64 bits but sizeof(!llvm.ptr<5>) = 32 bits, where
address space 5 is used for stack allocations). While this is merely
an overallocation in the case where a non-0 address space has pointers
smaller than the default, the existing code could cause OOB memory
accesses when sizeof(!llvm.ptr<N>) > sizeof(!llvm.ptr).

So, add an address spaces parameter to computeSizes in order to
partially resolve this class of bugs. Note that the LLVM data layout
in the conversion passes is currently set to "" and not constructed
from the MLIR data layout or some other source, but this could change
in the future.

Depends on D142159

Reviewed By: ftynse

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

Result must carry the polymorphic type information from the array.

`isChildOf` is a more concise name for the check. Also, there's no need to
test if the function is a fragment before doing `isChildOf` check.

Reviewed By: #bolt, rafauler, maksfb

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

Fix llvm-bolt-wrapper to skip output file checks if llvm-bolt exits with error
code.

Test Plan:
- checkout to revision with invalid NFC mismatch in `is-strip.s` test
  (e.g. 056af487~)
- run `nfc-check-setup.py`
- run `bin/llvm-lit -a tools/bolt/test/X86/is-strip.s`

Reviewed By: #bolt, rafauler

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

For example, in the following code

```

using namespace std::string_literals;

int main() {
    strin^ // Completes `string` instead of `std::string`
}
```

The using declaration would make completion drop the std namespace, even though it shouldn't.

printNamespaceScope() skips inline namespaces, so to fix this use
printQualifiedName() instead

See https://github.com/clangd/clangd/issues/1451

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

This reverts commit cce239c4.

HHVM calling conventions are unused. Remove them by partially reverting the commit.

Reviewed By: MaskRay, MatzeB

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

The sanitizer bots are failing with this test; they
impose a maximum 0x10000000000 size on allocations, and
malloc on darwin will let me malloc that much.  The
alternative to keep this would be to break it out into a
seperate test in TestProcessAIP and skip that if it's on
the sanitizer, but this is seeming too fragile IMO so I'm
punting it entirely.

It's part of the optimization pipeline, of which the legacy pass manager version is deprecated.

Reverting since the shared library builds are failing.

This reverts commit dcee1875.

An incorrect error was issued for procedure names occuring in OpenMP
regions with default clause set to NONE. Fix is to ignore all cases
where names are various kinds of procedures.

Fixes issue https://github.com/flang-compiler/f18-llvm-project/issues/1350

Reviewed By: peixin

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