We can already vectorise loops that involve int<>int, fp<>fp, int<>fp
and fp<>int conversions, however we didn't previously have any tests
for them. This patch adds some tests for each conversion type.
Details
Diff Detail
Event Timeline
Would it make sense to have all the conversion tests in a single file, as the tests are quite compact?
llvm/test/Transforms/LoopVectorize/AArch64/sve-conv-int-to-int.ll | ||
---|---|---|
6 ↗ | (On Diff #335497) | Do we still need this? IIRC most those checks have been removed by now? |
Sure, I can combine them into a single test if you think that's better? I wasn't sure whether in general we prefer to have more concise test files or to have fewer, larger files. I could create a file with a name like sve-type-conv.ll.
llvm/test/Transforms/LoopVectorize/AArch64/sve-conv-int-to-int.ll | ||
---|---|---|
6 ↗ | (On Diff #335497) | Yes you're right. When I created the patch originally I think we still needed them, but I'll rebase and remove them. |
Sounds good to me. I don't think there's a general answer really. In this case it seems like they all test the same/similar code path and there might be less processing overhead with fewer, larger files than with many small files.
llvm/test/Transforms/LoopVectorize/AArch64/sve-type-conv.ll | ||
---|---|---|
156–157 | Yeah, this is an artefact of clang. When compiling a loop such as this: void foo(float16_t *dst, uint64_t *src, long long n) { for (long long i = 0; i < n; i++) dst[i] = src[i]; } it generates IR with two-part conversions, i.e. uitfop + fptrunc. Not sure why, but I've changed the test anyway. |
I'm not sure why this test and the one below are using both a [u|s]itofp and an fptrunc, is it possible to just use uitofp i64 %0 to half here?