[LLVMdev] Contributing the Apple ARM64 compiler backend

Tim Northover t.p.northover at gmail.com
Mon Mar 31 14:07:11 PDT 2014


Hi James,

> Tim, am I correct in saying that you believe AArch64 -> ARM64 is the right way to go?

I think so, on the whole. I agree with your assessment that porting
performance improvements will be harder than porting correctness.

I also think we've made a few mistakes with the AArch64 backend that I
hope we'll be able to avoid in the merged version:

+ My load/store pattern idea has turned out to be a maintenance
nightmare. OK, it proves that TableGen *can* do the job, but I think
the C++ used in other targets is substantially clearer.
+ I don't think the v1iN approach to SISD operations has turned out
well. There's been far too much boiler-plate added to handle
operations that are essentially identical. In ARM64 there's the
beginnings of a MachineFunction pass to do the work of selecting SISD
instructions (ARM64AdvSIMDScalarPass.cpp). I'm hoping that will prove
cleaner in the end.
+ Sharing the @llvm.arm.neon space turned out rather more confusing
than I'd hoped. So many exceptions that the Clang benefits weren't
realised, but so much overlap that you never knew which intrinsic
would apply. It's also rather a layering violation.

On the other hand, it's been a while since I first saw ARM64 and I
know there were quite a few WTF moments when I did. I've been trying
to "improve" things since then, but some issues remain. The ones I can
remember are:

+ Instruction names are often inconsistent, particularly in the NEON
space. Sometimes v2i32, sometimes v2f32. Sometimes v2i32 takes that as
an arg, others it returns that, ... (I also think "vXiY" is unwieldy
and prefer "4s" etc, though that's personal).
+ Aliases seem more ad-hoc, with some fairly nasty hackery in
AsmParser and InstPrinter compared to AArch64.

I'd *really* love to hear any other people's WTFs (with either). Even
if we go with ARM64, they're issues that will soon become "that's just
how it's done" but right now we have an opportunity to remember them,
and hopefully fix them.

Cheers.

Tim.



More information about the llvm-dev mailing list