This patch adds a `ReturnLoc` field to the `Environment`, serving a similar to the `ThisPointeeLoc` field in the `DataflowAnalysisContext`. It then uses that (along with a new `VisitReturnStmt` method in `TransferVisitor`) to handle non-`void`-returning functions in context-sensitive analysis.
Reviewed By: ymandel, sgatev
Differential Revision: https://reviews.llvm.org/D130600
We would like to make the ACLE NEON and SVE intrinsics more useable by
gating them on the target, not by ifdef preprocessor macros. In order to
do this the types they use need to be available. This patches makes
__bf16 always available under AArch64 not just when the bf16
architecture feature is present. This bringing it in-line with GCC. In
subsequent patches the NEON bfloat16x8_t and SVE svbfloat16_t types
(along with bfloat16_t used in arm_sve.h) will be made unconditional
too.
The operations valid on the types are still very limited. They can be
used as a storage type, but the intrinsics used for convertions are
still behind an ifdef guard in arm_neon.h/arm_bf16.h.
Differential Revision: https://reviews.llvm.org/D130973
Close#56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for
fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions
and %B for the printf family of functions.
glibc 2.35 and latest Android bionic added %b/%B printf support. From
https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available
yet.
Like GCC, we don't test library support.
GCC 12 -Wformat -pedantic emits a warning:
> warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]
The behavior is not ported.
Note: `freebsd_kernel_printf` uses %b differently.
Reviewed By: aaron.ballman, dim, enh
Differential Revision: https://reviews.llvm.org/D131057
This connects the Symbolizer to the markup filter and enables the first
working end-to-end flow using the filter.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D130187
`transferBlock` and `computeBlockInputState` only read the
`BlockStates` vector for the predecessor block(s), and do not need to
mutate any of the contents. Only `runTypeErasedDataflowAnalysis`
writes into the `vector`, so simply down to an `ArrayRef`.
The `IR/AttributeTest.cpp` test fails to compile on Solaris:
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:223:36: error: no matching function for call to 'allocate'
AttrT::get(type, "resource", UnmanagedAsmResourceBlob::allocate(data));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:237:3: note: in instantiation of function template specialization 'checkNativeAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeAccess<AttrT, T>(builder.getContext(), llvm::makeArrayRef(data),
^
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:258:3: note: in instantiation of function template specialization 'checkNativeIntAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeIntAccess<DenseI8ResourceElementsAttr, int8_t>(builder, 8);
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:221:3: note: candidate template ignored: requirement '!std::is_same<char, char>::value' was not satisfied [with T = char]
allocate(ArrayRef<T> data, bool dataIsMutable = false) {
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:214:26: note: candidate function not viable: requires at least 2 arguments, but 1 was provided
static AsmResourceBlob allocate(ArrayRef<char> data, size_t align,
^
I suspect this happens because `char` is `signed` by default on Solaris.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D131148
This prepares patterns that sometimes are generated by the front-end
and would prohibit fusion of SDDMM flavored kernels.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D131126
This check is clearly incorrect, there's no way you should have an
eStateConnected event left on the queue if you've already launched
and hit a breakpoint in the program. This check fails running remotely
on Darwin systems and on one remote Linux platform. And if we do
find this failing somewhere, we should fix the bogus eStateConnected,
not the test.
The functions are effectively independent of the interface already, however, they take it as an argument for no reason.
The current state complicates reuse outside of MLIR.
Differential Revision: https://reviews.llvm.org/D131120
In D130807 we added the `skipprofile` attribute. This commit
changes the format so we can either `forbid` or `skip` profiling
functions by adding the `noprofile` or `skipprofile` attributes,
respectively. The behavior of the original format remains
unchanged.
Also, add the `skipprofile` attribute when using
`-fprofile-function-groups`.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D130808
This reverts commit d959324e1e.
The target_include_directories in the clang-fuzzer CMake files
are set to PRIVATE instead of PUBLIC to prevent the clang buildbots
from breaking when symlinking clang into llvm.
The expression evaluator fuzzer itself has been modified to prevent a
bug that occurs when running it without a target.
As discussed in [0], this diff adds the `skipprofile` attribute to
prevent the function from being profiled while allowing profiled
functions to be inlined into it. The `noprofile` attribute remains
unchanged.
The `noprofile` attribute is used for functions where it is
dangerous to add instrumentation to while the `skipprofile` attribute is
used to reduce code size or performance overhead.
[0] https://discourse.llvm.org/t/why-does-the-noprofile-attribute-restrict-inlining/64108
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D130807
`SymbolTable::lookupSymbolIn` is an expensive operation and we do not want to do it twice
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131145
Follow-up to D129097.
It is no longer a requirement that the `QualType` passed to to
`DataflowAnalysisContext::getStableStorageLocation()` is not null. A
null type pass as an argument is only applicable as the pointee type
of a `std::nullptr_t` pointer.
Differential Revision: https://reviews.llvm.org/D131109
This is required for using clang-query in the CI
Reviewed By: Mordante, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D130845
This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR--the type is intended
to remain an auxiliary type, not a real LLVM type. So no support is provided for
LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make
Type->dump() work properly).
Reviewed By: beanz, nikic, aeubanks
Differential Revision: https://reviews.llvm.org/D130592
Previously cf.br cf.cond_br and cf.switch always lowered to their LLVM
equivalents. These ops are all ops that take in some values of given
types and jump to other blocks with argument lists of the same types. If
the types are not the same, a verification failure will later occur. This led
to confusions, as everything works when func->llvm and cf->llvm lowering
both occur because func->llvm updates the blocks and argument lists
while cf->llvm updates the branching ops. Without func->llvm though,
there will potentially be a type mismatch.
This change now only lowers the CF ops if they will later pass
verification. This is possible because the parent op and its blocks will
be updated before the contained branching ops, so they can test their
new operand types against the types of the blocks they jump to.
Another plan was to have func->llvm only update the entry block
signature and to allow cf->llvm to update all other blocks, but this had
2 problems:
1. This would create a FuncOp lowering in cf->llvm lowering which is
awkward
2. This new pattern would only be applied if the containing FuncOp is
marked invalid. This is infeasible with the shared LLVM type
conversion/target infrastructure.
See previous discussions at
https://discourse.llvm.org/t/lowering-cf-to-llvm/63863 and
https://github.com/llvm/llvm-project/issues/55301
Differential Revision: https://reviews.llvm.org/D130971
This patch adds a DenseI1ArrayAttr to support arrays of i1. Importantly,
the implementation is as a simple `ArrayRef<bool>` instead of using bit
compression, which was problematic in DenseElementsAttr.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D130957
This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805
mentiond two compile-time string cases. And this patch partially fixes
one.
```
constexpr const char* foo() {
return "%s %d";
}
int main() {
printf(foo(), "abc", "def");
return 0;
}
```
This patch enables clang check format string for this:
```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
printf(foo(), "abc", "def");
~~~~~ ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
^~
%s
1 warning generated.
```
Reviewed By: aaron.ballman
Signed-off-by: YingChi Long <me@inclyc.cn>
Differential Revision: https://reviews.llvm.org/D130906
The kernel was rejecting sizeof(struct GPR) as it was not a multiple of
8. Add a padding field to fix that.
One also wonders whether "cpsr" is right register name for aarch64.
On targets with non-default program address space (e.g., Harvard
architectures), clang crashes when emitting Objective-C method metadata,
because the address of the method IMP cannot be bitcast to i8*. It similarly
crashes at messenger callsite with a failed bitcast.
Define the _imp field instead as i8 addrspace(1)* (or whatever the target's
program address space is). And in getMessageSendInfo(), create signatureType by
specifying the program address space.
Add a regression test using the AVR target. Test failed previously and passes
now. Checked codegen of the test for x86_64-apple-darwin19.6.0 and saw no
difference, as expected.
Reviewed By: rjmccall, dylanmckay
Differential Revision: https://reviews.llvm.org/D112113
This change separates computation of the actual parameters of the subset and
the materialization of subview/extract_slice. That way the users can still use
Linalg tiling logic even if they use different operations to materialize the
subsets.
Differential Revision: https://reviews.llvm.org/D131053
Using if (TARGET ${LLVM_NATIVE_ARCH}) only works if MLIR is built
together with LLVM, but not for standalone builds of MLIR. The
correct way to check this is
if (${LLVM_NATIVE_ARCH} IN_LIST LLVM_TARGETS_TO_BUILD), as the
LLVM build system exports LLVM_TARGETS_TO_BUILD.
To avoid repeating the same check many times, add a
MLIR_ENABLE_EXECUTION_ENGINE variable.
Differential Revision: https://reviews.llvm.org/D131071
This fixes warnings like these:
../lib/ExecutionEngine/Orc/MemoryMapper.cpp:364:9: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result]
joinErrors(std::move(Err),
^~~~~~~~~~ ~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D131056
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
In RVV, we use vwredsum.vs and vwredsumu.vs for vecreduce.add(ext(Ty A)) if the result type's width is twice of the input vector's SEW-width. In this situation, the cost of extended add reduction should be same as single-width add reduction. So as the vector float widenning reduction.
Differential Revision: https://reviews.llvm.org/D129994
It seems only the default implementation is ever used, so it doesn't seem
necessary to include this method in the interface.
Differential Revision: https://reviews.llvm.org/D130986
Since this now allows, the init/fini array iteration has been added in
a similar fashion to x86_64 and the corresponding test enabled.
Reviewed By: jeffbailey
Differential Revision: https://reviews.llvm.org/D131133
Petr Hosek