- Feb 28, 2023
-
-
Jean Perier authored
These compiler generated component descriptor include designators packaged as CLASS(*) for simplicity. HLFIR hit an assert in an std::get trying to recover an Expr<SomeChar> while translating the expression type. Use the dynamic type of the CLASS(*) expr in that case to recover the compiler length. Differential Revision: https://reviews.llvm.org/D144960
-
Adrian Vogelsgesang authored
Implements part of P1614R2 "The Mothership has Landed" Differential Revision: https://reviews.llvm.org/D132312
-
David Sherwood authored
This patch adds the LLVM IR intrinsics for the following: * uunpk (2 and 4 vectors) * sunpk (2 and 4 vectors) I have named the tests sve2p1-intrinsics-* because although the instructions are added as part of the SME2 feature they only operate on SVE vectors. NOTE: These intrinsics are still in development and are subject to future changes. Differential Revision: https://reviews.llvm.org/D142964
-
Nikita Popov authored
These were used to abstract between NewPM and LegacyPM. Now that the LegacyPM implementation is gone, we can fetch the analyses directly from the FAM.
-
Nikita Popov authored
The loop sink pass only does something if the function has profile data. Move the check for that before analyses are fetched, to avoid computing things like BFI or MSSA unnecessarily.
-
Valentin Clement authored
-
Nicolas Vasilache authored
This revision cleans up the implementation of hoist padding and extends it to also work in the absence of packing loops. This allows better composition when hoisting the padded result of a DPS operation. A systematic usage of RewriterBase is applied to the implementation. Depends on: D144856 Differential Revision: https://reviews.llvm.org/D144855
-
Nikita Popov authored
BlockFrequencyInfo should generally only be fetched in PGO builds where a PSI profile summary is available. However, LoopVectorize was fetching it unconditionally. This results in a small compile-time improvement for non-PGO builds. Differential Revision: https://reviews.llvm.org/D144953
-
Jean Perier authored
In hlfir, procedure designators are propagated as fir.box_proc. Derived type descriptors are compiler generated constant structure constructors. They contain CFPTR components for the type bound procedure addresses. Before being cast to an integer type so that they can be stored in the CFPTR components, the fir.box_proc addresses must be obtained with a fir.box_addr. Differential Revision: https://reviews.llvm.org/D144952
-
Jean Perier authored
Skip the parent components when they are not at the end of designators. Generate an hlfir.parent_comp for parent component at the end of designators. Differential Revision: https://reviews.llvm.org/D144948
-
Jean Perier authored
In Fortran, it is possible to refer to the "parent part" of a derived type as if it were a component: ```Fortran type t1 integer :: i end type type t2 integer :: j end type type(t2) :: a print *, a%t1%i ! "inner" parent component reference print *, a%t1 ! "leaf" parent component reference end ``` Inner parent component references can be dropped on the floor in lowering: "a%t1%i" is equivalent to "a%i". Leaf parent component references, however, must be taken care of. For scalars, "a%t1" is a simple addressc ast to "t1", for arrays, however, this creates an array section that must be represented with a descriptor (fir.box). hlfir.designate could have been extended to deal with this, but I think it would make hlfir.designate too complex and hard to manipulate. This patch adds an hlfir.parent_comp op that represents and implements leaf parent component references. Differential Revision: https://reviews.llvm.org/D144946
-
Valentin Clement authored
The bounds descriptor passed to the function is an array of [2, newRank] size. Update the code so the rank is retrieved from the second dimension and not the rank of the descriptor directly as it will be 2 in any case. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D144949
-
Ivan Kosarev authored
Reviewed By: foad Differential Revision: https://reviews.llvm.org/D144902
-
sgokhale authored
-
JP Lehr authored
Makes the info that is printed for kernel launches configurable for different plugins. Adds all machinery to print the detailed launch info that the current AMD plugin provides and includes e.g. register spill counts. The files msgpack.cpp, msgpack.def, and msgpack.h are copied from the old plugin and are untouched. The contents of UtilitiesHSA.cpp and .h are copied together from various files from the old plugin. The code was originally written by Jon Chesterfield. I updated the function and type names visible to the outside, i.e. in headers, to respect the LLVM conventions. Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D144521
-
sgokhale authored
Was observing test failure. Relanding the test
-
Benjamin Kramer authored
This reverts commit 89b144ec. See https://reviews.llvm.org/D141998 for a test case where this goes wrong.
-
Sacha Ballantyne authored
Previously COUNT would cast the mask input to logical<4> before passing it to the runtime function, this has been changed to allow different types of logical. Reviewed By: tblah Differential Revision: https://reviews.llvm.org/D144867
-
Ivan Kosarev authored
It is only used to infer the types of offset parameters in isel patterns, which we can specify directly. Reviewed By: piotr Differential Revision: https://reviews.llvm.org/D144890
-
dbakunevich authored
The new function has been added to SCEV that allows to raise the number 2 to the desired power. Authored-by: Dmitry Bakunevich Differential Revision: https://reviews.llvm.org/D144381
-
sgokhale authored
Previously, while calculating register usage due to invariants, it was assumed that invariant would always be part of widening instructions. This resulted in calculating vector register types for vectors which cant be legalized(check the newly added test for more details). An invariant might not always need a vector register. For e.g., invariant might just be used for iteration check. This patch checks if the invariant is part of any widening instruction and considers register usage accordingly. Fixes issue 60493 Differential Revision: https://reviews.llvm.org/D143422
-
Nicolas Vasilache authored
Depends on: D144717 Differential Revision: https://reviews.llvm.org/D144856
-
Nicolas Vasilache authored
Depends on: D144656 Differential Revision: https://reviews.llvm.org/D144717
-
Deniz Evrenci authored
All exceptions thrown in coroutine bodies are caught and unhandled_exception member of the coroutine promise type is called. In accordance with the existing rules of diagnostics related to exceptions thrown in functions marked noexcept, even if the promise type's constructor, get_return_object, or unhandled_exception throws, diagnostics should not be emitted. Fixes #48797. Differential Revision: https://reviews.llvm.org/D144352
-
Florian Hahn authored
Split tests for D144468. Adding a test with an icmp constant expression stopped CleanupPointerRootUsers from being called. Move it to a separate test.
-
Nikita Popov authored
Do not compute BFI if PGO is not used. This addresses the compile-time regression from https://reviews.llvm.org/D144769.
-
luxufan authored
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D144942
-
Max Kazantsev authored
This is already implied by getLoopPassPreservedAnalyses. Differential Revision: https://reviews.llvm.org/D144860 Reviewed By: nikic, skatkov
-
Dmitry Makogon authored
This better describes what this method does.
-
Dmitry Makogon authored
This fixes a possible issue when we could hoist an instruction up to a widenable condition intrinsic call without making sure its operands are available at hoisiting point. Recently insertion point finding algorithm changed a bit, so this availability check became necessary. Verifier would crash after we handled the following special case: L >u C0 && L >u C1 -> L >u max(C0, C1), Previously we would insert the new condition right before the widenable condition branch where all L operands were available. Now we may choose the widenable condition intrinsic call as insertion point and it may happen so that the L operands are computed after the call, so we have to make sure that L operands are available at the point we want to insert it. Differential Revision: https://reviews.llvm.org/D144944
-
Haojian Wu authored
-
Haojian Wu authored
-
Matthias Springer authored
Improve indentation for better readability. Before: ``` Domain: 0, Range: 2, Symbols: 2, Locals: 1 5 constraints (None Value Value Value Local const) 1 1 0 -1 0 0 = 0 0 1 -1 0 0 0 >= 0 0 0 1 -1 2 2 >= 0 0 0 -1 1 -2 -1 >= 0 0 -1 1 0 2 0 >= 0 ``` After: ``` Domain: 0, Range: 2, Symbols: 2, Locals: 1 5 constraints (None Value Value Value Local const) 1 1 0 -1 0 0 = 0 0 1 -1 0 0 0 >= 0 0 0 1 -1 2 2 >= 0 0 0 -1 1 -2 -1 >= 0 0 -1 1 0 2 0 >= 0 ``` Differential Revision: https://reviews.llvm.org/D144854
-
Dmitry Makogon authored
It hoits instruction without making sure its operands are available at hoisiting point.
-
Tobias Gysi authored
The revision renames LLVMOpsInterfaces.td since the the tablegen file contains op and type interfaces. Reviewed By: ftynse, Dinistro Differential Revision: https://reviews.llvm.org/D144875
-
Jun Zhang authored
(X & X) < 0 --> X == MinSignedC (X & X) > -1 --> X != MinSignedC Alive2: https://alive2.llvm.org/ce/z/_J5q3S Closes: https://github.com/llvm/llvm-project/issues/60957 Signed-off-by:
Jun Zhang <jun@junz.org> Differential Revision: https://reviews.llvm.org/D144777
-
Craig Topper authored
We can use the Record* to uniquely identify the Record without using its name.
-
LiaoChunyu authored
Similar to ARM and SystemZ. Related Patchs: D101778(preferZeroCompareBranch) https://reviews.llvm.org/rG9a9421a461166482465e786a46f8cced63cd2e9f ( == 0 to u< 1) Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D142071
-
Chuanqi Xu authored
I found the issue in a donwstream project. But the case looks fine in the upstream. Add the test to make sure that it wouldn't happen in the upstream.
-