Hi Richard,
On Fri, Oct 18, 2019 at 08:48:31PM +0100, Richard Earnshaw wrote:
>
> This series of patches rewrites all the DImode arithmetic patterns for
> the Arm backend when compiling for Arm or Thumb2 to split the
> operations during expand (the thumb1 code is unchanged and cannot
> benefit from early splitting as we are unable to expose the carry
> flag).
Very nice :-)
I have a bunch of testcases from when I did something similar for PowerPC
that I wanted to test... But I cannot get your series to apply. Do you
have a git repo I can pull from?
Here is one test case (it's a bit geared towards what our ISA can do):
===
typedef unsigned int u32;
typedef unsigned long long u64;
u64 add(u64 a, u64 b) { return a + b; }
u64 add1(u64 a) { return a + 1; }
u64 add42(u64 a) { return a + 42; }
u64 addm1(u64 a) { return a - 1; }
u64 addff(u64 a) { return a + 0xffffffffULL; }
u64 addH(u64 a) { return a + 0x123400005678ULL; }
u64 addH0(u64 a) { return a + 0x123400000000ULL; }
u64 addS(u64 a, u32 b) { return a + b; }
u64 addSH(u64 a, u32 b) { return a + ((u64)b << 32); }
u64 addB1(u64 a) { return a + 0x100000000ULL; }
u64 addB8(u64 a) { return a + 0x800000000ULL; }
u64 addSH42(u64 a, u32 b) { return a + ((u64)b << 32) + 42; }
u64 addSHm1(u64 a, u32 b) { return a + ((u64)b << 32) - 1; }
u64 addSHff(u64 a, u32 b) { return a + ((u64)b << 32) + 0xffffffffULL; }
===
rs6000 -m32 currently has non-optimal code for addm1, addSHm1; trunk arm
has non-optimal code for addH0, addSH, addB1, addB8, addSH42, addSHm1, and
addSHff if I understand well enough. So I'd love to see what it does with
your series applied :-)
Segher
