[Mlir-commits] [mlir] [memref] Support dense resources for memref-to-llvm (PR #79380)
Kunwar Grover
llvmlistbot at llvm.org
Wed Jan 24 18:01:54 PST 2024
Groverkss wrote:
> > This will probably have the same failures because you would interpret the bytes differently on big endian systems and the test will not match. So even if it is correct, your test will fail, because the answer is dependent on endianness.
> > This also needs some tests for non-splat values.
>
> Non-splat case added.
>
> I am a little confused by your comments: are you saying that if endianness matters it will fail no matter what, or even if this test passes it may not be correct.
>
> Thanks!
Thank you for adding the test.
I'll try to be more clear. Let's take this test:
```
// CHECK: llvm.mlir.global private constant @__constant_xf32_1(dense<[5.000000e-01, 2.500000e-01]> : tensor<2xf32>) {addr_space = 0 : i32} : !llvm.array<2 x f32>
memref.global "private" constant @__constant_xf32_1 : memref<2xf32> = dense_resource<NAME1>
```
Here, `dense<[5.000000e-01, 2.500000e-01]>` is how little endian systems interpret the byte array in NAME1:
```
NAME1: "0x080000000000003F0000803E"
```
For a big-endian system, this may be differently interpreted and there would be a different `dense<>` attribute. So the test output actually depends on the endianness of the system.
I think we need to disable these tests for big endian systems.
https://github.com/llvm/llvm-project/pull/79380
More information about the Mlir-commits
mailing list