[lldb/test] XFAIL TestFrameProviderCircularDependency.py on Windows
This patch disables TestFrameProviderCircularDependency.py on Windows
since the scripted frame provider uses SBTarget.FindFunctions which
doesn't seem to be working (according to TestTargetAPI.test_find_functions).
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
[lldb][test] DWARFASTParserClangTests: extract test setup into helper structure (#170132)
Depends on:
* https://github.com/llvm/llvm-project/pull/170249
We keep repeating the boilerplate of creating a
`DWARFASTParserClangStub` and `TypeSystemClangHolder` in all the
unit-test cases. Lets extract this into a helper to make the tests
easier to grok.
We actually only need the `DWARFASTParserClangStub` and a
`TypeSystemClangHolder` in one of the test cases. For the rest, we can
just re-use the typesystem/parser that the `YAMLModuleTester` created.
Re-using them makes it more straightforward to write test-cases because
we don't need to worry about which TypeSystem which DWARFParser created
types into.
[lldb][DWARFASTParserClang] Complete and make use of LLVM's RTTI support (#170249)
We almost had RTTI support for `DWARFASTParserClang`, but because
`classof` was protected, using `llvm::cast`/etc. on it would fail to
compile with:
```
llvm/include/llvm/Support/Casting.h:64:57: error: 'classof' is a protected member of 'DWARFASTParserClang'
64 | static inline bool doit(const From &Val) { return To::classof(&Val); }
| ^
llvm/include/llvm/Support/Casting.h:110:32: note: in instantiation of member function 'llvm::isa_impl<DWARFASTParserClang, lldb_private::plugin::dwarf::DWARFASTParser>::doit' requested here
110 | return isa_impl<To, From>::doit(*Val);
```
This patch makes `classof` public and turns `static_cast`s of
`DWARFASTParserClang` into `llvm::cast`s.
[lldb/test] Fix scripted frame provider tests on ARM32
On ARM32, FixCodeAddress unconditionally clears bit 0 (the Thumb bit)
from all code addresses, including synthetic frame PCs. This causes
test failures where synthetic PCs like 0xFFFF and 0xDEADBEEF become
0xFFFE and 0xDEADBEEE respectively.
This adjusts the tests to expect the modified PC values on ARM32.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
[llvm-exegesis] Make rvv/filter.test deterministic
This should prevent the flaky failures that have been plaguing the
buildbots since the test was introduced and allow for offline
investigation without disrupting CI.
Reviewers: topperc, mshockwave
Reviewed By: mshockwave
Pull Request: https://github.com/llvm/llvm-project/pull/170014
[lldb] Fix Doxygen warning in SBTrace.h (#170394)
Remove errant `\a` command before `<directory>` in `SaveToDisk`
documentation. The `\a` Doxygen command expects a word argument, but
`<directory>` starts with `<` which Doxygen interprets as HTML. This
fixes:
```
llvm-project/lldb/include/lldb/API/SBTrace.h:60:
Warning 564: Error parsing Doxygen command a: No word followed the command. Command ignored.
```
lldbgdbremote.md: Update `qWasmLocal` result description (#170393)
The current description mistakenly specified that an address of a local
value in some address space is returned. When testing this with Wasm
runtimes that already implement this command, it can be observed that
the value itself is returned. The value itself may be an address for
languages that use shadow stack in Wasm linear memory, but the value of
an arbitrary local does not always contain that address.
clang/AMDGPU: Enable opencl 2.0 features for unknown target (#170308)
Assume amdhsa triples support flat addressing, which matches
the backend logic for the default target. This fixes the
rocm device-libs build.
[HLSL][Matrix] Add support for Matrix element and trunc Casts (#168915)
fixes #168737
fixes #168755
This change fixes adds support for Matrix truncations via the
ICK_HLSL_Matrix_Truncation enum. That ends up being most of the files
changed.
It also allows Matrix as an HLSL Elementwise cast as long as the cast
does not perform a shape transformation ie 3x2 to 2x3.
Tests for the new elementwise and truncation behavior were added. As
well as sema tests to make sure we error n the shape transformation
cast.
I am punting right now on the ConstExpr Matrix support. That will need
to be addressed later. Will file a seperate issue for that if reviewers
agree it can wait.
[llvm][NFC] In `SetVector`, `contains` and `count` now automatically accept `const T *` arguments when the key is `T *` (#170377)
Also use `is_contained` to implement `contains`, since this tries the
`contains` member function of the set type first.
[LTT] mark the CFI jumptable naked on Windows (#170371)
We were not marking the `.cfi.jumptable` functions as `naked` on windows. The referenced bug (https://llvm.org/bugs/show_bug.cgi?id=28641#c3) appears to be fixed:
```bash
build/bin/opt -S -passes=lowertypetests -mtriple=i686-pc-win32 llvm/test/Transforms/LowerTypeTests/function.ll | build/bin/llc -O0
```
```
L_.cfi.jumptable: # @.cfi.jumptable
# %bb.0: # %entry
#APP
jmp _f.cfi at PLT
int3
int3
int3
#NO_APP
#APP
[12 lines not shown]
[CIR] Upstream vec shuffle builtins in CIR codegen (#169178)
This PR is part of #167752. It upstreams the codegen and tests for the
shuffle builtins implemented in the incubator, including:
- `vinsert` + `insert`
- `pblend` + `blend`
- `vpermilp`
- `pshuf` + `shufp`
- `palignr`
It does NOT upstream the `perm`, `vperm2`, `vpshuf`, `shuf_i` / `shuf_f`
and `align` builtins, which are not yet implemented in the incubator.
This _is_ a large commit, but most of it is tests.
The `pshufd` / `vpermilp` builtins seem to have no test coverage in the
incubator, what should I do?
Revert "[LSV] Merge contiguous chains across scalar types" (#170381)
Reverts llvm/llvm-project#154069. I pointed out a number of issues
post-merge, most importantly examples of miscompiles:
https://github.com/llvm/llvm-project/pull/154069#issuecomment-3603854626.
While the motivation of the change is clear, I think the implementation
approach is flawed. It seems like the goal is to allow elements like
`load <2xi16>` and `load i32` to be vectorized together despite the
current algorithm not grouping them into the same equivalence classes. I
personally think that if we want to attempt this it should be a more
wholistic approach, maybe even redefining the concept of an equivalence
class. This current solution seems like it would be really hard to do
bug-free, and even if the bugs were not present, it is only able to
merge chains that happen to be adjacent to each other after
`splitChainByContiguity`, which seems like it is leaving things up to
chance whether this optimization kicks in. But we can discuss more in
the re-land. Maybe the broader approach I'm proposing is too difficult,
and a narrow optimization is worthwhile. Regardless, this should be
reverted, it needs more iteration before it is correct.
[CIR] Lower calls to trivial copy constructor to cir::CopyOp (#168281)
This PR is a follow up to #167975 and replaces calls to trivial copy
constructors with `cir::CopyOp`.
---------
Co-authored-by: Andy Kaylor <akaylor at nvidia.com>
Co-authored-by: Henrich Lauko <henrich.lau at gmail.com>
