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
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
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
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
This patch fixes:
mlir/lib/Dialect/Arithmetic/Transforms/ExpandOps.cpp:161:52: error:
'static_assert' with no message is a C++17 extension
[-Werror,-Wc++17-extensions]
We could use knownbits on both operands for even more folds (and there are
already tests in place for that), but this is enough to recover the example
from:
https://github.com/llvm/llvm-project/issues/51934
(the tests are derived from the code in that example)
I am assuming no noticeable compile-time impact from this because udiv/urem
are rare opcodes.
Differential Revision: https://reviews.llvm.org/D116616
There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.
The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
- i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D116626
If any of the operands is NaN, return the operand instead of a new constant.
When the rhs operand is a constant, the second arith.cmpf+select ops will be folded away.
https://reviews.llvm.org/D117010 marks the two ops commutative, which will place the constant on the rhs.
Reviewed By: herhut
Differential Revision: https://reviews.llvm.org/D117011
db08df0570 does not work because part.relrDyn is
a unique_ptr and `reset` destroys the object which may still be referenced.
This commit uses the D114180 approach. Also improve the test to check that there
is no R_X86_64_RELATIVE.
Agreed policy is that RISC-V extensions that have not yet been ratified
should be marked as experimental, and enabling them requires the use of
the -menable-experimental-extensions flag when using clang alongside the
version number. These extensions have now been ratified, so this is no
longer necessary, and the target feature names can be renamed to no
longer be prefixed with "experimental-".
Differential Revision: https://reviews.llvm.org/D117131
binutils ar does not support one-dash long options (they conflict with
operation code and modifier flags).
```
% ar -help
ar: invalid option -- 'e'
...
% ar -version
ar: invalid option -- 'e'
...
% ar x --plugin=xx x.a # ok
% ar x -plugin=xx x.a
ar: two different operation options specified
% ar -plugin=/usr/lib/gcc/x86_64-linux-gnu/10/liblto_plugin.so x x.a
ar: x: No such file or directory
```
Drop one-dash long options to simplify code and match the usual practice for
command line utilities.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D116977
Matt Arsenault