This patch adds support for integer promotion for VP_LOAD and VP_STORE
by legalizing to extending and truncating forms of each, respectively.
|6,780 ms||x64 debian > libomp.tasking::omp50_taskwait_depend.c|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang -fopenmp -pthread -fno-experimental-isel -I /var/lib/buildkite-agent/builds/llvm-project/build/projects/openmp/runtime/src -I /var/lib/buildkite-agent/builds/llvm-project/openmp/runtime/test -L /var/lib/buildkite-agent/builds/llvm-project/build/lib -fno-omit-frame-pointer -I /var/lib/buildkite-agent/builds/llvm-project/openmp/runtime/test/ompt /var/lib/buildkite-agent/builds/llvm-project/openmp/runtime/test/tasking/omp50_taskwait_depend.c -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/openmp/runtime/test/tasking/Output/omp50_taskwait_depend.c.tmp -lm -latomic && /var/lib/buildkite-agent/builds/llvm-project/build/projects/openmp/runtime/test/tasking/Output/omp50_taskwait_depend.c.tmp
Yes you should be able to test this with RISCV. Anything that's not i1/i8/i16/i32 but is less than i64 will need promoting. Also see D108288 for examples.
I don't think we expect EVL to need promoting - do we? It should always be a legal target-specific type, reported by TLI.getVPExplicitVectorLengthTy(). I don't know how well we're asserting on that right now.
GetPromotedInteger -> ZExtPromotedInteger. We need to force the upper bits to 0.
5 -> 6 if I've counted the number of operands correctly.
Should we assert that the store isn't indexed since this call would be incorrect if it was?
GetPromotedInteger -> ZExtPromotedInteger.
Added more legalization to this patch rather than putting it into another patch. Added another form of getLoadVP that was needed by the legalization. Expanded tests to cover vector splitting.
Why does this use isIndexed() but load uses N->getAddressingMode() == ISD::UNINDEXED. Are the interfaces for checking indexed different for loads and stores?
|7700 ↗||(On Diff #371782)|
Why should this be different than the assert in getLoad?
|2 ↗||(On Diff #371791)|
We shouldn't put RISC-V tests in Generic unless we know the target is built. So either this needs to use REQUIRES: or we put it in CodeGen/RISCV. I prefer the latter as that's where I've seen all other target-specific legalization tests go.
Again, I'm not sure whether we ever need to promote the length - it's always a target-specific legal integer type, isn't it?
|2774 ↗||(On Diff #371966)|
return Lo would simplify this flow a bit
|4344 ↗||(On Diff #371966)|
true here is FillWithZeroes - I don't think we need to do this for VP widening, since we're passing the original length along, right?
|5223 ↗||(On Diff #371966)|
same comment about FillWithZeroes