This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][ARM] Cleanup DImode shifts


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]