These instructions don't swap lanes so make them valid.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Agreed, they don't swap lanes. They can write to only bottom/top halfs, but that's fine. So looks like a straightforward change to me.
Comment Actions
Hey. Can you explain what makes an instruction validForTailPredication? I think I've lost track. And what do you mean by "swap lanes" in this case?
Comment Actions
We're allowing instructions which produce a vector and where the output lanes are only dependent upon the same lane on the input register(s). So when I say 'swap', I should say 'exchange'.
Comment Actions
OK. I'm not sure if that is enough, if I am understanding correctly. What if we load a v8i16, extend that into two v4i32's using something like a VMULL, then narrow that back into a single v8i16. I don't think this is something that autovec will produce (yet), but could come up from intrinsics in a way that people are likely to write. Something like this:
#include <arm_mve.h>
void test(short *x, short *y, short *z, int n) {
while(n > 0) {
int pred = vctp16q(n);
int16x8_t a = vldrhq_z_s16(x, pred);
int16x8_t b = vldrhq_z_s16(y, pred);
int32x4_t top = vmulltq_int(a, b);
int32x4_t bot = vmullbq_int(a, b);
int16x8_t rtop = vqshrnbq(vuninitializedq_s16(), bot, 16);
int16x8_t rbot = vqshrntq(rtop, top, 16);
vstrhq_p_s16(z, rbot, pred);
x += 8;
y += 8;
z += 8;
n -= 8;
}
}I'm pretty sure that tail predicating this would not be valid, as the top bits of one of the mul's could be cut off.
Comment Actions
Yes, the problem there is that the number of lanes isn't the same throughout the loop, not necessarily that we're using a narrowing operation. Do you know if there's a nice way to query operand/result types at the MI level?
Comment Actions
Not sure. I think they are just register types at the instruction level. I thought that was why we excluded many instructions (like vmull and vshrn), because they all change the types, and that changing of the types probably means that the tail predication might not be valid.
From IR I think that would be <8 x i16> sext to <8 x i32>, so the number of lanes would be the same, but the types (and lanes they are computed in) changes.
PS. I noticed VFMA.f32 isn't marked as valid. I think that's one that should certainly be OK.