similar to: [LLVMdev] Contributing the Apple ARM64 compiler backend (re. lldb bits)

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

On Thu, Apr 3, 2014 at 11:50 AM, Jevin Sweval <jevinsweval at gmail.com> wrote: > On Wed, Apr 2, 2014 at 1:57 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: >> Hi - >> >> Not sure if anyone else saw this or cares about a decompiler (not personally >> tested) >> https://github.com/draperlaboratory/fracture >> >> I wonder if

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

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

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

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

Hi Chandler, > I'd like to hear from the existing AArch64 backend maintainers if they have > any concerns about getting #1 done right away? I agree (with my AArch64 maintainer hat on). The goal of merging these two backends will hopefully do a lot to make sure the eventual code is better than what exists now in either individual directory; and doing the real work towards that will be

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

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

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm

> 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

On Mon, Mar 31, 2014 at 1:01 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 31 March 2014 20:55, Tim Northover <t.p.northover at gmail.com> wrote: > > I'd almost prefer to leave it in for the bugs to be discovered > > (perhaps after some simple tests of our own). ARM went wirthout > > FastISel support on Linux for years simply because it was declared

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

On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after hitting a trap. On x86_64, the trap instruction is executed, and then you stop, so the PC is left after the stop. On arm64, when execution halts the pc is still pointing at the trap instruction. > > I don't think lldb should be in the business of telling

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

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

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: