similar to: [LLVMdev] Contributing the Apple ARM64 compiler backend

Hi all, Firstly thanks so much to Apple for open sourcing this and Tim for going through the effort of committing it! Along with Bradley I've been looking at this today from a perspective of working out how best to get this merge completed. The one sentence summary is "I think we should use ARM64 as a base". My view on the backends is that the ARM64 backend is more performant but

AArch64AddressTypePromotion.cpp does a fair bit of work to help make these things work out well. It could probably be generalized for non-AArch64 targets as per the comment in the file header. > On Jun 26, 2014, at 10:42 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > Cool HW trick. :) > Are those 'sxtw' ops free? > That’ll depend on the details of the

On Mar 28, 2014, at 4:23 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Mar 28, 2014, at 4:17 PM, Chris Lattner <clattner at apple.com> wrote: > >> On Mar 28, 2014, at 3:32 PM, Bob Wilson <bob.wilson at apple.com> wrote: >>> There are new conflicts several times a day, on average. I rebased them on Wednesday on top of svn 204791. If you want to

I just tried to apply the patches to the community clang and llvm tips and there are conflicts. Do you guys plan to rebase the patches? I vote for importing the ARM64 backend into the public tree as soon as possible. Thanks, Ana. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kristof Beyls Sent: Friday, March 28, 2014 2:44

This sounds reasonable. Thanks, all. > - CSE of ADRP optimization (Jiangning) Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences. -Jim On Apr 12, 2014, at 12:08 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi again, > > Having heard no howls of protest, those of us remaining on the > Wednesday decided to get down to

Hi Renato, >> 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. > > Count me in. Would that be a different triple? arm64-linux-gnu? Yep. "--target arm64-linux-gnu" should behave basically the same as aarch64-linux-gnu, except ending up in the ARM64 backend.

On Fri, Mar 28, 2014 at 2:31 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Tim Northover" <t.p.northover at gmail.com> > > To: "Renato Golin" <renato.golin at linaro.org> > > Cc: "LLVM Developers Mailing List" <LLVMdev at cs.uiuc.edu> > > Sent: Friday, March 28, 2014 3:47:49 PM

On Mar 28, 2014, at 3:32 PM, Bob Wilson <bob.wilson at apple.com> wrote: > There are new conflicts several times a day, on average. I rebased them on Wednesday on top of svn 204791. If you want to try them out, it would be best to roll back to that revision. > > I’ll rebase them one more time when we commit them, but it’s such a moving target (and takes a fair bit of work), that

Hi all, A bunch of us met at EuroLLVM to discuss the planned merge of the two current AArch64 backends in the tree. The primary question was which backend should form the basis of the merge (since the core .td files aren't directly mergeable), with code being cherry-picked from the other on a case-by-case basis. There were factors to consider both ways, but I think the key points of interest

Hi Hal, > Is a different target triple the right thing to do here? I think that would introduce a ton of user confusion. How about we keep the target triples as they are, and add some other way to choose the desired backend? In the short term, it's almost essential. Both of these targets are going to be existing simultaneously for a while and all the LLVM tools (for testing if nothing

> Are these two backends ABI compatible? They should be, where there's overlap. AArch64 doesn't have any MachO support at the moment. ARM64 does have ELF support (obviously with less testing than AArch64's). Any ABI discrepancy would be considered a bug. > If I have a toolchain setup for the existing aarch64-linux-gnu triple, could > I try the new backend and still have

hello everyone: On this boring weekend, I tried compile R-trunk on windows 11 arm64 using clangarm64+msys2 on macbook m1 , it surprisingly easy to compiled and run. more investigation and test and code modify need to be done ,but IMO this is a good beginning !! to compile R on windows 11 arm64 just need : 1 svn checkout R-trunk and add USE_LLVM=YES in MKRules.dist or Mkrules.local 2 install

Hi all, It’s been two weeks since I sent the last merge progress email, so here is an update. TL;DR: Almost done! Tim is considering suggesting making the final switchover sometime next week. This would be the final push, where AArch64 gets deleted and ARM64 gets renamed to AArch64, and would signal the end of the merge process. If any of you know of any reason why these two loving

Hi Jiangning, On Apr 14, 2014, at 10:31 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Jim, > > 2014-04-15 4:28 GMT+08:00 Jim Grosbach <grosbach at apple.com>: > This sounds reasonable. Thanks, all. > > > - CSE of ADRP optimization (Jiangning) > > Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences.

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

Hi folks, As Tim pointed out, we recently had the opportunity to collect 64-bit benchmark performance data for GCC 4.9, AArch64 and ARM64 compilers on a real hardware. It is a cortex-a53 device. Due to proprietary reasons we cannot share the full hardware configuration. The preliminary results were shared at the hackers lab at EuroLLVM yesterday. For those who could not make it, below is

Hi Gerolf, Sorry for the delayed response. I had to get permission to share more details. I am allowed to share relative numbers but not absolute numbers. Any missing test is due to runtime failures (e.g., gcc failure due to the fused multiply pattern bug which Tim fixed later on). Thanks, Ana. Benchmarks ARM64 vs GCC 4.9 % ARM64 vs AArch64 % ARM64 vs AArch64 patched %

HI James, Thanks for your reply and hints on what can be done for the Aarch64 backend optimization for llvm We have SPEC license and v8 hardware. So I will start looking into it warm regards Manjunath On Wed, Jun 25, 2014 at 8:42 PM, James Molloy <james.molloy at arm.com> wrote: > Hi Manjunath, > > At the time of writing that status we had only done our initial analysis. >

Hi Sanjay, The behaviour I’m talking about I’ve actually pinned down to CodeGenPrepare not working too well with ISA’s that don’t have a good scaled load. I have a patch to fix it that is going through performance testing now. Your testcase seems specific to x86 – for aarch64 we get the rather spiffy: _Z3fooPii: // @_Z3fooPii // BB#0:

Hi all, Thanks to everyone's hard work over the last few months, the last child of the AArch64/ARM64 merge issue (http://llvm.org/PR19392) has just been resolved. So I think it's time to finish the job. I'd like to delete the AArch64 target and move ARM64 into its place: for now we'll accept both aarch64 and arm64 triples in all places, and they will all be redirected to the