================
@@ -398,7 +398,7 @@ mlir::Type CIRGenTypes::convertType(QualType type) {
/*is_scalable=*/true);
break;
case BuiltinType::SveBFloat16:
- resultType = cir::VectorType::get(builder.getFp16Ty(), 8,
+ resultType = cir::VectorType::get(builder.getBfloat16Ty(), 8,
----------------
banach-space wrote:
Good question!
In most cases, we rely on LIT tests to verify the compiler (and to exercise
every possible code path). For this particular line, I added the following
test:
https://github.com/llvm/llvm-project/blob/0c62d834abff9b180def1b32d3cf9c225d504994/clang/test/CodeGen/AArch64/sve/len.c?plain=1#L95-L105
Note that it does not verify that `bfloat` is used. It doesn't have to though -
the input argument is not used (so we don't check it). Instead, what's key is
that:
* `@llvm.vscale.i64()` is called to get the value of SVE's `vscale`.
* `vscale` is multiplied by `8`: `mul nuw i64 [[VSCALE]], 8` (there's `8`
`bfloat` values in a 128-bit vector granule).
Since this PR adds tests that properly exercise `bfloat16`(see e.g.
`test_svdup_n_bf16_z`), I have refrained from updating `test_svlen_bf16` (i.e.
the original test). But ultimately, the bug sneaked it because the testing
wasn't adequeate.
IMHO, it is neither possible nor desirable to check every single line of code
(that would mean _a lot_ of tests and be very hard to maintain). LLVM tests
tend to focus on what matters to users and there's so many of them that the
coverage is actually pretty good (but not 100%). We do have gaps though and
this is a very good example đ
https://github.com/llvm/llvm-project/pull/223932
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
