Currently clangd will display useless inlay hint for dependent type in
structured binding, e.g.
```
template <class T>
void foobar(T arg) {
auto [a/*: <dependent type>*/, b/*: <dependent type>*/] = arg;
}
```
Differential Revision: https://reviews.llvm.org/D157956
The testcases mainly cover three situations:
- the arguments which should be immediates are non immediates.
- the immediate is out of upper limit of the argument type.
- the immediate is out of lower limit of the argument type.
Depends on D155829
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D157570
The function emitFunctionEntryLabel does not look at whether or not a function is a leaf when setting the entry flags,
and instead blindly marks all functions as non-leaf routines. Change it to check if a function is a leaf function and
mark it accordingly.
Use raw strings instead of regular strings when escapes are used for
regex matches or arbitrary letters rather than C-style characters.
This fixes `SyntaxWarning`s:
```
TestRunner.py:205: SyntaxWarning: invalid escape sequence '\c'
"""
TestRunner.py:1566: SyntaxWarning: invalid escape sequence '\s'
match = _caching_re_compile("^\s*%else\s*(%{)?").search(ln)
```
Differential Revision: https://reviews.llvm.org/D158356
This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](https://reviews.llvm.org/rGb56e65d31825fe4a1ae02fdcbad58bb7993d63a7), `fastmath` attributes in the complex dialect are directly mapped to the corresponding LLVM fastmath flags.
In this diff,
- Definition of FastMathAttr as a custom attribute in the Complex dialect that inherits from the EnumAttr class.
- Definition of ComplexFastMathInterface, which is an interface that is implemented by operations that have a complex::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and arithmetic operations in the Complex dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags
NOT in this diff (but planned and progressively implemented):
- Documentation of flag meanings
- Support the fastmath flag conversion to Arith dialect
- Folding/rewrite implementations that are enabled by fastmath flags (although it's the original motivation to support the flag)
RFC: https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D156310
Check for 'wasm.' prefix before proceeding, and a bit of common handling
for some of the intrinsics therein.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D158370
All dependencies on code from LoopVectorize.cpp have been
removed/refactored. Move the ::execute implementations to other recipe
definitions in VPlanRecipes.cpp
This patch removes the `getBBIDOrNumber` which was introduced to allow emitting version 1.
Reviewed By: shenhan
Differential Revision: https://reviews.llvm.org/D158299
This is useful when user already have partially-scf'ed IR or other ops with nested regions (e.g. linalg.generic).
Also, improve error message and pass docs.
Differential Revision: https://reviews.llvm.org/D158349
Consume the dbg. prefix before looking further. Also merge the matched
path.
Differential Revision: https://reviews.llvm.org/D158341
Reviewed By: nikic
Some opcodes in MIR are defined to be convergent by the target by setting
IsConvergent in the corresponding TD file. For example, in AMDGPU, the opcodes
G_SI_CALL and G_INTRINSIC* are marked as convergent. But this is too
conservative, since calls to functions that do not execute convergent operations
should not be marked convergent. This information is available in LLVM IR.
The new flag MIFlag::NoConvergent now allows the IR translator to mark an
instruction as not performing any convergent operations. It is relevant only on
occurrences of opcodes that are marked isConvergent in the target.
Differential Revision: https://reviews.llvm.org/D157475
It is more efficient to gate on the prefix before checking for the
individual cases. Also, the regexps weren't consistent about escaping '.'.
Differential Revision: https://reviews.llvm.org/D157923
Reviewed By: arsenm
This patch adds support for loading IRDL operations that are
using optional or variadics operands and results.
If an operation declares more than one optional/variadic operand
or result, then it requires the segment sizes in the attribute
dictionary, and otherwise it is computed using the number of
operands or results.
Currently, a variadic operand or result definiton expects all
operands and results in that definition to have the same type.
This restriction will be removed in a following patch.
Depends on D153983
Reviewed By: Mogball, unterumarmung
Differential Revision: https://reviews.llvm.org/D154073
This reverts commit 62b2b39992.
This is the error reported by the buildbot:
/home/buildbots/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/mlir/lib/Dialect/IRDL/IRDLLoading.cpp:97:22: error: no member named 'reduce' in namespace 'std'
int32_t sum = std::reduce(denseSegmentSizes.asArrayRef().begin(),
Full details are available at:
https://lab.llvm.org/buildbot#builders/21/builds/78689
I happened to notice this page (https://clang-analyzer.llvm.org/filing_bugs.html)
was a bit stale, so I've updated and simplified it a bit.
* The page is now explicitly in UTF-8 (NFC)
* We no longer talk about Bugzilla and Apple's bug reporting tools, but
instead link to GitHub's issues page
* We now link to the general LLVM documentation on how to submit a bug
Differential Revision: https://reviews.llvm.org/D158360
This patch adds support for loading IRDL operations that are
using optional or variadics operands and results.
If an operation declares more than one optional/variadic operand
or result, then it requires the segment sizes in the attribute
dictionary, and otherwise it is computed using the number of
operands or results.
Currently, a variadic operand or result definiton expects all
operands and results in that definition to have the same type.
This restriction will be removed in a following patch.
Depends on D153983
Reviewed By: Mogball, unterumarmung
Differential Revision: https://reviews.llvm.org/D154073
Ensure we only use the eflags results from shift instructions when it won't cause stalls
shift by variable causes stalls as it has to preserve eflags when the shift amount was zero, so we're better off using a separate test
Before this patch, we had visitRecordInitializer() and
visitArrayInitializer(), which were different from the regular visit()
in that they expected a pointer on the top of the stack, which they
initialized. For example, visitArrayInitializer handled InitListExprs by
looping over the members and initializing the elements of that pointer.
However, this had a few corner cases and problems. For example, in
visitLambdaExpr() (a lambda is always of record type), it was not clear
whether we should always create a new local variable to save the lambda
to, or not. This is why https://reviews.llvm.org/D153616 changed
things around.
This patch changes the visiting functions to:
- visit(): Always leaves a new value on the stack. If the expression
can be mapped to a primitive type, it's just visited and the value is
put on the stack. If it's of composite type, this function will
create a local variable for the expression value and call
visitInitializer(). The pointer to the local variable will stay on
the stack.
- visitInitializer(): Visits the given expression, assuming there is a
pointer on top of the stack that will be initialized by it.
- discard(): Visit the expression for side-effects, but don't leave a
value on the stack.
It also adds an additional Initializing flag to differentiate between the initializing and non-initializing case.
Differential Revision: https://reviews.llvm.org/D156027
ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
Error(L, "msg");
return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158275
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.
To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.
Related issue: https://github.com/llvm/llvm-project/issues/59751
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D141053
This used to crash the interpreter, either because we ran into the
assertion in CheckMutable() or because we accessed a Descriptor* pointer
preceding the field of a record. Those are preceded by an
InlineDescriptor though.
Differential Revision: https://reviews.llvm.org/D152132
We only did this for primitive temporaries.
Unfortunately, the existing Pointer::toAPValue() won't do here, since
we're expected to set an rvalue on the LifetimeExtendedTemporaryDecl.
Differential Revision: https://reviews.llvm.org/D144457
Previous commit on ALU made an error by changing CV_ROR to CVROR. Revert it.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D158261
This is a reland of 28134a29fd which was
reverted due to behavioral differences between 32 and 64 bit builds that
have since been fixed.
Differential Revision: https://reviews.llvm.org/D158217
MSVC has a __cpuidex function implemented to call the underlying cpuid
instruction which accepts a leaf, subleaf, and data array that the output
data is written into. This patch adds this functionality into clang
under the cpuid.h header. This also makes clang match GCC's behavior.
GCC has had __cpuidex in its cpuid.h since 2020.
