The code size cost model for most targets uses the legalization cost for the type of the pointer of a load. If this load is followed directly by a trunc instruction, and is the only use of the result of the load, only one instruction is generated in the target assembly language. This adds a check for this case, and uses the target type of the trunc instruction if so.

This did not show any changes in CTMark code size benchmarks.

Reviewers: paquette, samparker, dmgreen

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

When preprocessing "# ARG" in function-like macro expansion,
the preprocessor needs to pop the previously-pushed '#' token
from the end of the resulting token sequence after detecting the
argument name.  The code to do this was just wrong in a couple of
ways.

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

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

This wasn't running at -O0, and causing crashes for AMDGPU. AMDGPU
needs this to match the addressing modes of stack access instructions,
which is even more important at -O0 than with optimizations.

It currently costs nothing to run ahead of time, so just always enable
it.

In a future change, AMDGPU will have 2 emergency scavenging indexes in
some situations. The secondary scavenging index ends up being used
recursively when the scavenger calls eliminateFrameIndex for the
emergency spill slot. Without this, it would end up seeing the same
register which was just scavenged in the parent call as free, inserts
a second emergency spill to the same location and returns the same
register when 2 unique free registers are required.

We need to only do this if the register is used. SystemZ uses 2
scavenging slots, but calls the scavenger twice in sequence and not
recursively. In this case the previously scavenged register can be
re-clobbered, but is still tracked in the scavenger until it sees the
deferred restore instruction.

For some reason we pass around the alignment in bits as uint64_t. Two
places were truncating it to unsigned, and losing bits in extreme
cases.

The attribute queries semi-consistently check the attribute set, and
then fallback to checking the callee's attributes.

Insert it for call return values only for now, which is the only case
the DAG handles also.

This should have been part of D116239.

Also remove some bogus `std::forward`s. My impression is that these
forwards were actually harmless, because `ranges::begin(FWD(t))` is
always identical to `ranges::begin(t)` (except when it's ill-formed,
and that can't happen in this case). However, they're also superfluous
and don't reflect the wording in the standard, so let's eliminate them.

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

This overload parses a pipeline string that contains the anchor operation type, and returns an OpPassManager
corresponding to the provided pipeline. This is useful for various situations, such as dynamic pass pipelines
which are not anchored within a parent pass pipeline.

fixes #52813

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

I missed a variable when reformatting the tests. This fixes that.

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

This is the 5th of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.

Depends on D115368

Reviewed By: ldionne, #libc_abi

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

Currently, the `InitByte...` classes inherit from `GuardObject` so they can
access the `base_address`, `init_byte_address` and `thread_id_address`. Then,
since `GuardObject` needs to call `acquire`/`release`/`abort_init_byte`, it uses
the curiously recurring template pattern (CRTP). This is rather messy.

Instead, we'll have `GuardObject` contain an instance of `InitByte`, and pass it
the addresses it needs in the constructor. `GuardObject` doesn't need the
addresses anyways, so it makes more sense for `InitByte` to keep them instead of
`GuardObject`. Then, `GuardObject` can call `acquire`/`release`/`abort` as one
of `InitByte`'s member functions.

Organizing things this way not only gets rid of the use of the CRTP, but also
improves separation of concerns a bit since the `InitByte` classes are no longer
indirectly responsible for things because of their inheritance from
`GuardObject`. This means we no longer have strange things like calling
`InitByteFutex.cxa_guard_acquire`, instead we call
`GuardObject<InitByteFutex>.cxa_guard_acquire`.

This is the 4th of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.

Depends on D115367

Reviewed By: ldionne, #libc_abi

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

Right now, GuardObject is in charge of both reading and writing to the guard
byte, and co-ordinating with the InitByte... classes. In order to improve
separation of concerns, create a separate class responsible for managing the
guard byte and use that inside GuardObject.

This is the 3rd of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.

Depends on D110088

Reviewed By: ldionne, #libc_abi

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

By relying on PlatformSupportsThreadID, InitByteGlobalMutex disregards
the GetThreadID template argument, rendering it useless.

This is the 2nd of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.

Depends on D109539

Reviewed By: ldionne, #libc_abi

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

This will make the naming more consistent with what it's called in the
rest of the file.

This is the 1st of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.

Reviewed By: ldionne, #libc_abi

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

Some functions were added to x86_64 that were untested on Aarch64. Now
that I've had an opportunity to test them, they all work on Aarch64 with
the minor formatting change included.

Reviewed By: sivachandra

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

Dynamic batch for rescale, gather, max_pool, avg_pool, conv2D and depthwise_conv2D. Split helper functions into a separate header file.

Reviewed By: rsuderman

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

ShapedType was created in a time before interfaces, and is one of the earliest
type base classes in the ecosystem. This commit refactors ShapedType into
an interface, which is what it would have been if interfaces had existed at that
time. The API of ShapedType and it's derived classes are essentially untouched
by this refactor, with the exception being the API surrounding kDynamicIndex
(which requires a sole home).

For now, the API of ShapedType and its name have been kept as consistent to
the current state of the world as possible (to help with potential migration churn,
among other reasons). Moving forward though, we should look into potentially
restructuring its API and possible its name as well (it should really have "Interface"
at the end like other interfaces at the very least).

One other potentially interesting note is that I've attached the ShapedType::Trait
to TensorType/BaseMemRefType to act as mixins for the ShapedType API. This
is kind of weird, but allows for sharing the same API (i.e. preventing API loss from
the transition from base class -> Interface). This inheritance doesn't affect any
of the derived classes, it is just for API mixin.

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

This field allows for defining a code block that is placed in both the interface
and trait declarations. This is very useful when defining a set of utilities to
expose on both the Interface class and the derived attribute/operation/type.

In non-static methods, `$_attr`/`$_op`/`$_type` (depending on the type of
interface) may be used to refer to an instance of the IR entity. In the interface
declaration, this is an instance of the interface class. In the trait declaration,
this is an instance of the concrete entity class (e.g. `IntegerAttr`, `FuncOp`, etc.).

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

Apply scale may encounter scalar, tensor, or vector operations. Expand the
lowering so that it can lower arbitrary of container types.

Reviewed By: NatashaKnk

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

This introduces clang command line support for new Armv8.8-A and
Armv9.3-A Hinted Conditional Branches feature, previously introduced
into LLVM in https://reviews.llvm.org/D116156.

Patch by Tomas Matheson and Son Tuan Vu.

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

This method simply forwards to populateFunctionLikeTypeConversionPattern,
which is more general. This also helps to remove special treatment of FuncOp from
DialectConversion.

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

Filter string_view from the nullptr diagnosis of bugprone-string-constructor to prevent duplicate warnings with bugprone-stringview-nullptr

Updates the check and tests to not diagnose the null case for string_view (but retains it for string). This prevents the check from giving duplicate warnings that are caught by bugprone-stringview-nullptr ([[ https://reviews.llvm.org/D113148 | D113148 ]]).

Reviewed By: ymandel

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

Since Ret parameter is never meant to be nullptr, let's pass it by reference instead of a raw pointer.

Reviewed By: dblaikie

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

    This patch adds support for type back referencing, allowing demangling of
    compressed mangled symbols with repetitive types.

Signed-off-by: Luís Ferreira <contact@lsferreira.net>

Reviewed By: dblaikie

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

    This patch adds support for identifier back referencing allowing compressed
    mangled names by avoiding repetitiveness.

Signed-off-by: Luís Ferreira <contact@lsferreira.net>

Reviewed By: dblaikie

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

This patch implements simple demangling of two basic types to add minimal type functionality. This will be later used in function type parsing. After that being implemented we can add the rest of the types and test the result of the type name.

Reviewed By: dblaikie

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

bugprone-stringview-nullptr was not initially written with tests for return statements. After landing the check, the thought crossed my mind to add such tests. After writing them, I realized they needed additional handling in the matchers.

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

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: ymandel, xazax.hun

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

This avoids spurious failures in some environemnts.
Similar change to eafc64ed.

This reverts commit 9e634b35.

and remove associated make<XXX> calls.

My x86-64 `lld` is ~5KiB smaller.

Sometimes a macro invocation will look like an argument list
declaration.  Improve the check to detect this situation and not
try to modify the macro invocation.

Thanks to Nathan James for the fix.

- Ignore implicit typedefs (e.g. compiler builtins)
- Improve lexing state machine to locate void argument tokens
- Add additional return_t() macro tests
- clang-format control in the test case file
- remove braces around single statements per LLVM style guide

Fixes #43791

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

Switch to the D114180 approach which is simpler and allows gnuHashTab/hashTab to
switch to unique_ptr.