search for: arm64e

Based on work by Neil Williams (codehelp at debian.org) and Anil Singhar (anil.singhar at linaro.org), this patch introduces arm64 support. Signed-off-by: Steve Capper <steve.capper at linaro.org> --- Makefile | 3 +- usr/include/arch/arm64/klibc/archconfig.h | 17 ++++++++++ usr/include/arch/arm64/klibc/archsetjmp.h | 20 ++++++++++++

Commit-ID: e4a2c914446ba907c5aaccf6ae1d089a09d21df7 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e4a2c914446ba907c5aaccf6ae1d089a09d21df7 Author: Steve Capper <steve.capper at linaro.org> AuthorDate: Mon, 11 Nov 2013 17:04:12 +0000 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Mon, 11 Nov 2013 19:31:31 -0800 [klibc] arm64: Add arm64 support

Commit-ID: 45647d9f97cac184d399eae9bcbe24aef2223f70 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=45647d9f97cac184d399eae9bcbe24aef2223f70 Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Mon, 11 Nov 2013 19:33:40 -0800 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Mon, 11 Nov 2013 19:33:40 -0800 [klibc] arm64: remove useless

This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It takes the CPU as parameter and return true if the CPU is preempted. Then kernel can break the spin loops upon the retval of vcpu_is_preempted. As kernel has used this interface, So lets support

This patch set aims to support the vcpu_is_preempted() functionality under KVM/arm64, which allowing the guest to obtain the VCPU is currently running or not. This will enhance lock performance on overcommitted hosts (more runnable VCPUs than physical CPUs in the system) as doing busy waits for preempted VCPUs will hurt system performance far worse than early yielding. We have observed some

From: Zengruan Ye <yezengruan at huawei.com> This patch set aims to support the vcpu_is_preempted() functionality under KVM/arm64, which allowing the guest to obtain the vcpu is currently running or not. This will enhance lock performance on overcommitted hosts (more runnable vcpus than physical cpus in the system) as doing busy waits for preempted vcpus will hurt system performance far

From: Zengruan Ye <yezengruan at huawei.com> This patch set aims to support the vcpu_is_preempted() functionality under KVM/arm64, which allowing the guest to obtain the vcpu is currently running or not. This will enhance lock performance on overcommitted hosts (more runnable vcpus than physical cpus in the system) as doing busy waits for preempted vcpus will hurt system performance far

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 %

Hello, This series introduces arm64 support to klibc. I've rebased the work from Neil Williams and Anil Singhar into the following three patches. Most of the code changes are due to new syscall implementations being needed for arm64 as a only a minimal set of syscalls are defined in the arm64 kernel. This series is to be applied against the latest klibc, just after 25a66fa README.klibc:

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

The arm-smmu driver can COMPILE_TEST on x86, so expand this to also enable the IORT code so it can be COMPILE_TEST'd too. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- drivers/acpi/Kconfig | 2 -- drivers/acpi/Makefile | 2 +- drivers/acpi/arm64/Kconfig | 1 + drivers/acpi/arm64/Makefile | 2 +- drivers/iommu/Kconfig | 1 + 5 files changed, 4 insertions(+),

Hello, Here is V2 of the arm64 support for klibc patch set. Notable changes since the original series: * fp regs dropped from setjmp/longjmp * chmod, lstat and stat re-implemented with *at functions. * open64 merged into open. As with the original, this series is to be applied against the latest klibc, just after 25a66fa README.klibc: update build information V2 has been tested on x86_64

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

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

When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Signed-off-by:

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

When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Signed-off-by:

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