[PATCH]Clang and AArch64 backend patches to support sshll/ushll instructions

[Tim Northover]

Hi Hao,

Thanks for working on this, it's good to see more NEON progress.

I realise the 32-bit ARM target already has special intrinsics for
these instructions, but I think they should be representable in normal
assembly. For example, I think

int64x2_t do_shift(int32x2_t in) { return vshll_n_s32(in, 3); }

is basically:

define <2 x i64> @do_shift(<2 x i32> %in) {
    %tmp = sext <2 x i32> %in to <2 x i64>
    %shift = shl <2 x i64> %in, <2 x i64> <i64 3, i64 3>
    ret <2 x i64> %shift
}

The _high_ variants will probably involve a shufflevector to
implemenet a concatenation.

Longer term, we know more native vector code is coming (OpenCL,
auto-vectoriser, ...) so it makes even more sense than before to do
this without convenient hacks.

Other than that, it mostly looks sensible. Some smallish issues, LLVM side:
+ In AsmParser, there's already isUImm<3>, isUImm<4> and isUImm<5>. No
need for extra code I think.
+ It looks like there are lines longer than 80 characters in AArch64InstrNEON.td
+ The spacing is generally dodgy there: we use 2 spaces
+ There's some duplication going on: imm0_7 is surely pretty much the
same thing as uimm3 from AArch64InstrInfo.td.

Clang side:
+ What's 'H' standing for in arm_neon.td? It's not necessarily a bad
choice, just curious.
+ In NeonEmitter.cpp: typestr.startswith("Q") looks dodgy. What
happens if someone writes "UQi" for example?

I've also not looked at AArch64ISelLowering.cpp in detail yet. Changes
there are probably going to be radically different if we go for proper
CodeGen instead of the intrinsic route.

Cheers.

Tim.