[LLVMdev] Contributing the Apple ARM64 compiler backend

[Eric Christopher]

> The big pain issues I see merging from ARM64 to AArch64 are:
> 1.      Apple have created a fairly complete scheduling model already for
> ARM64, and we'd have to merge the partial? model in AArch64 and theirs. We
> risk regressing performance on Apple's targets here, and we can't determine
> ourselves whether we have or not. This is not ideal.
> 2.      Porting over the DAG-to-DAG optimizations and any other
> optimizations that rely on the tablegen layout will be very tricky.
> 3.      The conditional compare pass is fairly comprehensive - we'd have to
> port that over or rewrite it and that would be a lot of work.
> 4.      A very quick analysis last night indicated that ARM64 has
> implemented just under half of the optimizations we discovered opportunities
> for in SPEC and EEMBC. That's a fairly comprehensive number of
> optimizations, and they won't all be easy to port.

There's already a working fast isel port as well. Though I'm not sure
how well tested that's been on linux.

Tim?

>
> The big pain issues I see going the other way, from AArch64 to ARM64 are:
> 1.      Functional regressions. These are fairly easy to detect - we have a
> bunch of test suites and codegen faults are easy to spot (incorrect
> results). I've spent the day looking at the MC Hammer failures, and there
> aren't many very bad ones. Certainly none that are horrendous to fix.

Nice.

> 2.      Performance on A53. But isn't it really just the scheduling model
> that needs updating? There are no A53-specific optimizations in
> Target/AArch64 that I know of.
>

Agreed. There could be some small codegen changes, I'm not familiar
with the A53.

-eric

> Cheers,
>
> James
>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>> On Behalf Of Bradley Smith
>> Sent: 31 March 2014 18:19
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
>>
>> > 1. Import the ARM64 backend into the public tree so it's easily
>> > accessible for everyone to investigate.
>> > 2. Test it. Benchmark it. Explore it. Get data for the community to
>> > work with about the state of the back end. ARM has some excellent data
>> > that will help guide us here.
>> > 3. Identify the core backend to build on and to merge features and
>> > tuning from the other to. The data I have seen so far leads me to
>> > believe ARM64 is the correct choice here, but that's a decision
>> > primarily for the contributors above.
>> > 4. Clean up the codebase (C++11-ify it, for example), fix any
>> > regressions and test failures identified in benchmarking.
>> >
>> > This will give us a backend that is a superset of both ARM64 and
>> > AArch64 in terms both of performance and functionality. We can then
>> > consolidate to a single backend, named AArch64 for consistency with the
>> > current public tree.
>>
>> Our MC Hammer[0] testing on this shows that the ARM64 backend has
>> around a
>> 4% failure rate overall, one criteria for a successful merge would
> certainly
>> be to retain the level architectural correctness that is currently present
>> in the AArch64 backend.
>>
>> Looking at the failures that are present in the ARM64 backend, it doesn't
>> look like it would be too much work to fixup the MC layer to get this
>> testsuite passing.
>>
>> [0] http://llvm.org/devmtg/2012-04-12/Slides/Richard_Barton.pdf
>>
>> Regards,
>> Bradley Smith
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev