similar to: [LLVMdev] RFC: Remove AArch64 backend & rename ARM64 -> AArch64

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 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 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

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

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

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 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 Jiangning, On Apr 15, 2014, at 11:12 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Quentin, > > Thanks for your feedback! >> ​ARM64 generates pseudo instructions ARM64::MOVaddr and friends in ISEL stage, which intends to guarantee address serialization (page address + in-page address), and exposes adrp finally by pass ExpandPseudoInsts. The assumption of

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, Apart from whether fast-isel should be enabled or disabled (I think enabled, personally), I haven't heard any dissenting voices about how to attack the merge problem yet. Tim, am I correct in saying that you believe AArch64 -> ARM64 is the right way to go? Does anyone disagree with that approach? Cheers, James ________________________________________ From: llvmdev-bounces at

All, Attached below are the patches that make up the Apple ARM64 compiler backend (in addition to compiler_rt, libc++ and lldb support), and we'd like to start the process of integrating them into mainline LLVM. We and ARM have discussed a general approach to integrating them into mainline and look forward to working through this with the community at large. First a bit of context to help

Hi Tim, I just read this thread and I see that you mentioned the buildbot and my name. > - LLVM test suite enabled in the buildbot and testing ARM64 (Gabor) What exactly I can do to help you with the merge process? Best regards, Gabor Ballabas -------------- next part -------------- An HTML attachment was scrubbed... URL:

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.

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

% clang -S -O3 -mcpu=cortex-a57 -ffast-math -Rpass-analysis=loop-vectorize dot.c dot.c:15:1: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop [-Rpass-analysis=loop-vectorize] } ^ dot.c:15:1: note: could not determine the original source location for :0:0 I found “llvm-as < /dev/null | llc -march=aarch64 -mattr=help” which listed a

Hi everyone, I'm a member engineer of linaro's llvm team,coming from Spreadtrum.I am a new person on LLVM.Now I'm writing a Target Parser for AArch64,so options parsing of AArch64 about cpu & arch & fpu can be summary to one place. In the TargetParser,we assume "aarch64" and "arm64" are synonyms of armv8a(as they are only for armv8a,people usually do

Thanks Martin, I'm generating the code using LLVM (writing llvm::Triple myself and llvm::TargetRegistry::lookupTarget is working), and that's how my bitcode is generated then using LLC to cross-compile that. So using armv7-win32-msvc is getting me a bit closer, but what CPU, raspberry pi 3 is running a Cortext-A53, but when I specify that in -mcpu argument I get this error: > llc.exe

Is there a way to use LLC to cross-compile some code to run on Windows IOT on Raspberry Pi ? I was able to convince LLVM to spit out some bitcode for this, but when I try llc it dumps: llc.exe test.bc -o test.obj -filetype=obj -O3 -mtriple=aarch64-win32-msvc -mcpu=cortex-a53 Wrote crash dump file "C:\Users\clovett\AppData\Local\Temp\llc.exe-4990d8.dmp" 0x0000000000000000

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