Hi Ramana,
> Thanks for this patch set - What I'm missing in this is any analysis as
> to what's the impact on code generation for neon intrinsics that use
> uint64_t ? Especially things like v<add/sub/...>_u64 ?
Well things like this continue to work exactly like before:
uint64x1_t f20(uint64x1_t x, uint64x1_t y)
{
return vshl_u64 (x, y);
}
uint64x1_t f21(uint64x1_t x)
{
return vshl_n_u64 (x, 10);
}
f20:
vmov d16, r0, r1 @ int
vmov d17, r2, r3 @ int
vshl.u64 d16, d16, d17
vmov r0, r1, d16 @ int
bx lr
f21:
vmov d16, r0, r1 @ int
vshl.i64 d16, d16, #10
vmov r0, r1, d16 @ int
bx lr
As you can see there is a problem with the uint64x1_t type which for a strange
reason maps to DImode, so avoiding Neon here would avoid lots of moves...
The vadd_u64 variant emits the right code already:
uint64x1_t f22(uint64x1_t x, uint64x1_t y)
{
return vadd_u64 (x, y);
}
f22:
adds r0, r0, r2
adc r1, r1, r3
bx lr
Wilco
