[PATCH][AArch64] Prefer ldp x, x to ldr q

[James Molloy]

Hi Tim,

I didn't do it that way, I did it a more braindead way because I was feeling braindead at the time. However, you've convinced me that it's a hack rather than a fudge. (hack > fudge > "heuristic" > heuristic ?)

I have a prototype patch that adds a target hook to describe the cost of keeping a set of types live over a call. For most targets this would be zero, for AArch64 (128-bit vectors only) it'd be the cost of a spill and fill. I've then taught the SLP vectorizer to find the set of live values at all CallInsts between the first and last instructions, which was more code than I'd hoped.

Erik's recent SLP change has seemingly broken all my testcases though, so in the meantime I've committed the non-contentious DAGCombine part.

Cheers, and thanks for pushing me in the right direction,

James

-----Original Message-----
From: Tim Northover [mailto:tnorthover at apple.com] 
Sent: 01 August 2014 18:03
To: James Molloy
Cc: Tim Northover; Chad Rosier; llvm-commits
Subject: Re: [PATCH][AArch64] Prefer ldp x, x to ldr q

Hi James,

> I just extended it to work with all 128-bit loads, and that caused some bad behaviour.
> 
> What we're saying is (assume one scalar load has a cost of 1):
> <2 x i32> costs 1
> <4 x i32> costs 4

How did you extend it? I’d expect you to return 2 for <4 x i32>, along some kind of 2*<64-bit cost> algorithm, rather than N*<scalar>, if we’re really pretending to model some ldp effect.

> So I think it only applies to <2 x i64> or <2 x double>. And yes, this whole thing is making me feel very dirty inside - if there's a better way, I don't know of it :(

I think if we really can only make it apply to the 64-bit element case, that’s the strongest evidence yet that the whole approach is wrong. How can it be OK to merge loads to form a <4 x i32> ldr, but not a <2 x i64> one? They’re exactly the same instruction.

Cheers.

Tim.