similar to: Upstreaming Exception Handling support for Windows on ARM64

On Mon, 21 May 2018, Hayden Livingston wrote: > So are you saying that LLVM can be built as ARM64 on Windows now? > CMake doesn't show me an option for ARM64 when using MSVC on Windows. > I have the latest CMake. I'm saying that LLVM can produce code for the Windows/ARM64 target. As for compiling LLVM itself to run on ARM64 on Windows, I don't know how to configure MSVC to

Ok. How much work was it to enable ARM64 codegen? Is it is significantly more work than for Linux targets? Are there any special relocations in ARM64 land? On Mon, May 21, 2018 at 3:38 AM, Martin Storsjö <martin at martin.st> wrote: > On Mon, 21 May 2018, Hayden Livingston wrote: > >> So are you saying that LLVM can be built as ARM64 on Windows now? >> CMake doesn't

On Mon, 21 May 2018, Hayden Livingston wrote: > Ok. How much work was it to enable ARM64 codegen? Is it is > significantly more work than for Linux targets? Are there any special > relocations in ARM64 land? It was surprisingly little work, I'd say. Yes, Windows uses COFF, and there's a separate set of relocations for each architecture. Probably not more work than for Linux

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

On 6 July 2017 at 11:02, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Grang, Mandeep Singh wrote: >> I would like to hear the community's thoughts on these proposals. >From the perspective of the recent focused effort on reproducible builds, I think this is excellent. >> We ideally want to compare rel vs >> rel+asserts vs debug with Linux vs

On Mar 26, 2014, at 7:55 AM, Peter Robinson <pbrobinson at gmail.com> wrote: > On Wed, Mar 26, 2014 at 11:45 AM, Vinay <vinay.nair at novanet.net> wrote: >> Hi, >> >> I wanted to build opus along with PJSIP for iOS for the architecture arm64. >> I wanted to know if opus supports arm64? > > The opus code builds fine on ARM64 on Linux at least,

Hi, I wanted to build opus along with PJSIP for iOS for the architecture arm64. I wanted to know if opus supports arm64? -- Vinay Nair vinay.nair at novanet.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20140326/e617665a/attachment.htm

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, I wanted to build opus along with PJSIP for iOS for the architecture arm64. I wanted to know if opus supports arm64? -- Vinay Nair vinay.nair at novanet.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20140326/8576b64e/attachment-0001.htm

On Sun, Jul 19, 2020 at 5:04 PM Zhenyu Zheng <zhengzhenyulixi@gmail.com> wrote: > > Hi oVirt, > > We are currently trying to make oVirt work on ARM64 platform, since I'm quite new to oVirt community, I'm wondering what is the current status about ARM64 support in the oVirt upstream, as I saw the oVirt Wikipedia page mentioned there is an ongoing efforts to support ARM

Hi, At the Build conference recently, Microsoft had a session about Windows on ARM(64), [1]. As case example of a large, nontrivial app rebuilt for this arch, they demonstrated VLC. The presentation claimed that this was built with MSVC, with zero changes to the source. This actually isn't true; the app that was demonstrated was actually built with Clang and LLD with mingw-w64 as SDK

I have used the patch to build opus 1.1. Although I have not tried the latest git master, will try that. Will that work for armv7, armv7s and arm64? On Wed, Mar 26, 2014 at 11:01 PM, Martin Storsj? <martin at martin.st> wrote: > On Wed, 26 Mar 2014, Jonathan Lennox wrote: > > >> On Mar 26, 2014, at 7:55 AM, Peter Robinson <pbrobinson at gmail.com> wrote: >>

So are you saying that LLVM can be built as ARM64 on Windows now? CMake doesn't show me an option for ARM64 when using MSVC on Windows. I have the latest CMake. On Mon, May 21, 2018 at 2:34 AM, Martin Storsjö via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > At the Build conference recently, Microsoft had a session about Windows on > ARM(64), [1]. As case example of

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 Zengruan, Thank you for the patch! Yet something to improve: [auto build test ERROR on kvmarm/next] [also build test ERROR on kvm/linux-next linus/master v5.5-rc3 next-20191220] [cannot apply to arm64/for-next/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in

On 11/08/2013 09:12 AM, Steve Capper wrote: > + > +/* > + * x19-x28 are callee saved, also save fp, lr, sp. > + * d8-d15 are also callee saved. > + */ > + > +struct __jmp_buf { > + uint64_t __gregs[13]; > + uint64_t __fpregs[8]; > +}; > + Since the index of these arrays have no connection with what is stored in them, they should be named fields in the structure,

Not subscribed to the list, sorry to mess up the message threading - but to touch on one question that was raised earlier in the day, Bob Wilson wrote: > On Mar 28, 2014, at 4:23 PM, Jevin Sweval <jevinsweval at gmail.com> wrote: > >> Is the LLDB patch missing? I only see libc++, compiler-rt, LLVM, and Clang patches > > We have a patch for LLDB but it is combined with a

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

Hi, On Thu, Jan 8, 2015 at 11:13 PM, Vikram Karve <Vikram.Karve at citrix.com> wrote: > > Hi, > Has anyone attempted to build the Speex codec for ARM64? If so, could you please share the build instructions or some references detailing what scripts need to be updated. I don't have access to any ARM64 hardware, but you might want to try --disable-neon, see:

Hi, Has anyone attempted to build the Speex codec for ARM64? If so, could you please share the build instructions or some references detailing what scripts need to be updated. Regards, Vikram