diff options
author | Rik Huijzer <github@huijzer.xyz> | 2023-10-23 17:02:52 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-10-23 17:02:52 +0200 |
commit | c836b4ad6cd005766dfe1b29c81fe1b667e50e1c (patch) | |
tree | 8e02998da0f50370c11069a05f2e149842539859 /lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h | |
parent | 600e38b11ae79b0c0cd10416b2a7a78f654cf5b2 (diff) | |
download | llvm-c836b4ad6cd005766dfe1b29c81fe1b667e50e1c.zip llvm-c836b4ad6cd005766dfe1b29c81fe1b667e50e1c.tar.gz llvm-c836b4ad6cd005766dfe1b29c81fe1b667e50e1c.tar.bz2 |
[mlir] Verify TestBuiltinAttributeInterfaces eltype (#69878)
Fixes #61871 and fixes #60581.
This PR fixes two small things. First and foremost, it throws a clear
error in the `-test-elements-attr-interface` when those tests are called
on elements which are not an integer. I've looked through the
introduction of the attribute interface
(https://reviews.llvm.org/D109190) and later commits and see no evidence
that the interface (`attr.tryGetValues<T>()`) is expected to handle
mismatching types.
For example, the case which is given in #61871 is:
```mlir
arith.constant sparse<[[0, 0, 5]], -2.0> : vector<1x1x10xf16>
```
So, a sparse vector containing `f16` elements. This will crash at
various locations when called in the test because the test introduces
integer types (`int64_t`, `uint64_t`, `APInt`, `IntegerAttr`), but as I
said in the previous paragraph: I see no reason to believe that the
implementation of the interface is wrong here. The interface just
assumes that clients don't do things like `attr.tryGetValues<APInt>()`
on a floating point `attr`.
Also I've added a test for the implementation of this interface by the
`sparse` dialect. There were no problems there. Still, probably good to
increase code coverage on that one.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h')
0 files changed, 0 insertions, 0 deletions