Follow-up to #154288.
With HwModes involved, we used to analyze the same encoding multiple
times (unless `-suppress-per-hwmode-duplicates=O2` is specified). This
affected the build time and made the statistics inaccurate.
From the point of view of the generated code, this is an NFC.
Improve error handling in ObjectFileWasm by using helpers that wrap
their result in an llvm::Expected. The helper to read a Wasm string now
return an Expected<std::string> and I created a helper to parse 32-bit
ULEBs that returns an Expected<uint32_t>.
This PR fixes the access to bitfields inside a union.
Previously, we were using a `getMemberOp` to access the field, but
because it is a union, `getMemberOp` would always use index `0`.
For example, given:
```c
typedef union {
int x;
int y : 4;
int z : 8;
} demo;
```
```mlir
!rec_demo = !cir.record<union "demo" {!s32i, !u8i, !u8i}>
```
In the case of:
```c
d.y = 2;
```
It would generate:
```mlir
cir.get_member %0[0] {name = "y"} : !cir.ptr<!rec_demo> -> !cir.ptr<!s32i>
```
with a return type of `!s32i`, when it should be `!u8i`.
the get_member verifier would detect that the return type does not match
the `y` member.
To fix this, we now use `bitcast` to get the start of the union.
We have a flag that tracks whether a `CXXThisExpr` refers to a `*this`
capture in a lambda with a dependent explicit object parameter; this is
to mark it and member accesses involving it as dependent because there
is no other way to track that (DREs have a similar flag); when
instantiating the lambda, we need to always rebuild the `CXXThisExpr` to
potentially clear that flag if the explicit object parameter is no
longer dependent.
Fixes#154054.
Makes sure UnconventionalAssignOperatorCheck checks if the types
reference the same entity, not the exact declaration.
This adds a new matcher to support this check.
This fixes a regression introduced by #147835. Since this regression was
never released, there are no release notes.
Fixes#153770
This is a follow-up to #150963. X86 HLT instruction may appear in the
user-level code, in which case we should treat it as a terminator.
Handle it as a non-terminator in the Linux kernel mode.
added getName method in SBModule.h and .cpp in order to get the name of
the module from m_object_name.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
Recent changes introduced custom lowering for bf16 fdiv on targets that
support bf16 trans instructions, but only covered the unsafe version.
This PR extends that support to the safe variant.
For the safe version, the op is lowered by converting to float,
performing the div in float, and converting the result back to bf16.
This matches the behavior on targets that don't support bf16 trans
instructions.
Fixes SWDEV-550381.
Exposes the `tensor.extract_slice` reshaping logic in
`BubbleUpExpandShapeThroughExtractSlice` and
`BubbleUpCollapseShapeThroughExtractSlice` through two corresponding
utility functions. These compute the offsets/sizes/strides of an extract
slice after either collapsing or expanding.
This should also make it easier to implement the two other bubbling
cases: (1) the `collapse_shape` is a consumer or (2) the `expand_shape`
is a consumer.
---------
Signed-off-by: Ian Wood <ianwood@u.northwestern.edu>
When assigning numbers to registers, skip any with neither uses nor
defs. This is will not have any impact at all on the final SASS but it
makes for slightly more readable PTX. This change should also ensure
that future minor changes are less likely to cause noisy diffs in
register numbering.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 10 instances that rely on this "redirection". Since the
redirection doesn't improve readability, this patch replaces SmallSet
with SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
If an array initializer list leaves eight or more elements that require
zero fill, we had been generating an individual zero element for every
one of them. This change instead follows the behavior of classic
codegen, which creates a constant structure with the specified elements
followed by a zero-initializer for the trailing zeros.
Fix incorrect super-register lookup when copying from $wzr on subtargets
that lack zero-cycle zeroing but support 64-bit zero-cycle moves.
When copying from $wzr, we used the wrong register class to lookup the
super-register, causing
$w0 = COPY $wzr
to get expanded as
$x0 = ORRXrr $xzr, undef $noreg, implicit $wzr,
rather than the correct
$x0 = ORRXrr $xzr, undef $xzr, implicit $wzr.
Before this change, `-quiet` mode in clang-tidy generated meaningless
messages `xxx warnings generated` in output:
```cpp
// main.cpp
#include <iostream>
int main() {
std::cout << 42;
}
```
```console
> clang-tidy -checks='-*,readability-magic-numbers' -quiet main.cpp
82 warnings generated.
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
```
As you can see, `82 warnings generated.` does not say much `quiet` mode,
this patch removes this message completely:
```console
> ./build/bin/clang-tidy -p build -checks='-*,readability-magic-numbers' -quiet main.cpp
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
```
In contrast, when running without `quiet`, It gives some meaningful
information because we know how many messages were suppressed thus
calculating total messages count:
```console
> clang-tidy -checks='-*,readability-magic-numbers' main.cpp
82 warnings generated.
main.cpp:4:16: warning: 42 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
4 | std::cout << 42;
| ^
Suppressed 81 warnings (81 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
```
Fixes#47042
This is a continuation of #153494. In a WebAssembly file, the "name"
section contains names for the segments in the data section
(WASM_NAMES_DATA_SEGMENT). We already parse these as symbols, and with
this PR, we now also create sub-sections for each of the segments.
In C++, it can be assumed the same linkage will be computed for all
redeclarations of an entity, and we have assertions to check this.
However, the linkage for a declaration can be requested in the middle of
deserealization, and at this point the redecl chain is not well formed,
as computation of the most recent declaration is deferred.
This patch makes that assertion work even in such conditions.
This fixes a regression introduced in
https://github.com/llvm/llvm-project/pull/147835, which was never
released, so there are no release notes for this.
Fixes#153933
Revert llvm/llvm-project#154018 changes due to excessive _false
positives_. The warning caused multiple benign reports in large
codebases (e.g. _Linux kernel_, _Fuchsia_, _tcpdump_). Since many of
these concatenations are intentional and follow project style rules, the
diagnostic introduced more false positives than value. This will be
revisited as a potential `clang-tidy` check instead.
This patch works towards consolidating all Clang debug-info into the
`clang/test/DebugInfo` directory
(https://discourse.llvm.org/t/clang-test-location-of-clang-debug-info-tests/87958).
Here we move only the `clang/test/CodeGen` tests.
The list of files i came up with is:
1. searched for anything with `*debug-info*` in the filename
2. searched for occurrences of `debug-info-kind` in the tests
I created a couple of subdirectories in `clang/test/DebugInfo` where I
thought it made sense (mostly when the tests were target-specific).
There's a couple of tests in `clang/test/CodeGen` that still set
`-debug-info-kind`. They probably don't need to do that, but I'm not
changing that as part of this PR.
This can happen when JIT code is run, and we can't symbolize those
frames, but they should remain numbered in the stack. An example
spidermonkey trace:
```
#0 0x564ac90fb80f (/builds/worker/dist/bin/js+0x240e80f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#1 0x564ac9223a64 (/builds/worker/dist/bin/js+0x2536a64) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#2 0x564ac922316f (/builds/worker/dist/bin/js+0x253616f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#3 0x564ac9eac032 (/builds/worker/dist/bin/js+0x31bf032) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#4 0x0dec477ca22e (<unknown module>)
```
Without this change, the following symbolization is output:
```
#0 0x55a6d72f980f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x55a6d72f980f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x55a6d7421a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x55a6d742116f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x55a6d80aa032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#4 0x2c803bd8f22e (<unknown module>)
```
The last frame has a duplicate number. With this change the numbering is
correct:
```
#0 0x5620c58ec80f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x5620c58ec80f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x5620c5a14a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x5620c5a1416f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x5620c669d032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#5 0x349f24c7022e (<unknown module>)
```
The changes from https://github.com/llvm/llvm-project/pull/136855 missed
a change with atomic assignment constraints. This fixes a bug where we'd
accidentally drop a non-atomic-to-atomic conversion step.
Fixes#154157
co-authored-by: @ahatanak
This PR adds the following basic math functions for BFloat16 type along
with the tests:
- fromfpbf16
- fromfpxbf16
- ufromfpbf16
- ufromfpxbf16
---------
Signed-off-by: Krishna Pandey <kpandey81930@gmail.com>
Previously, we fold `(vfmv.s.f (extract_subvector X, 0))` into X when
X's type is the same as `vfmv.s.f`'s result type. This patch generalizes
it by folding it into insert_subvector when X is narrower and
extract_subvector when X is wider.
Co-authored-by: Craig Topper <craig.topper@sifive.com>
If alignment inference happens after NVPTXLowerArgs these addrspace wrap
intrinsics can prevent computeKnownBits from deriving alignment of
loads/stores from parameters. To solve this, we can insert an alignment
annotation on the generated intrinsic so that computeKnownBits does not
need to traverse through it to find the alignment.
This patch replaces SmallSet<T *, N> with SmallPtrSet<T *, N>. Note
that SmallSet.h "redirects" SmallSet to SmallPtrSet for pointer
element types:
template <typename PointeeType, unsigned N>
class SmallSet<PointeeType*, N> : public SmallPtrSet<PointeeType*, N>
{};
We only have 10 instances that rely on this "redirection". Since the
redirection doesn't improve readability, this patch replaces SmallSet
with SmallPtrSet for pointer element types.
I'm planning to remove the redirection eventually.
