[LLVMdev] Contributing the Apple ARM64 compiler backend

[Amara Emerson]

*Flexes buck-passing muscles*

Looks like James wrote the original chunk of that quote.

Amara

> -----Original Message-----
> From: Eric Christopher [mailto:echristo at gmail.com]
> Sent: 24 June 2014 15:23
> To: Manjunath N; Amara Emerson
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
> 
> On Tue, Jun 24, 2014 at 2:45 AM, Manjunath N <manjunath.dn at gmail.com>
> wrote:
> >
> >
> > Eric Christopher <echristo <at> gmail.com> writes:
> >
> >>
> >> > 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.
> > Eric,
> > You mention that there a quite a few  optimization opportunities in SPEC
> > 2000/ EEMBC.
> > I am looking to optimize the Aarch64 backend. Could you please let me
> know
> > the big optimizations possible?
> >
> 
> Wasn't me here. I was just on the thread. Might have been Amara?
> 
> -eric