search for: armv8a

Hi, A64 versus A32/T32 code generation is controlled by the -target option which I don’t believe is under discussion here. James On 18 May 2016, at 13:17, Bruce Hoult <bruce at hoult.org<mailto:bruce at hoult.org>> wrote: Note that armv8a modifies the A32 and T32 instruction sets, and is therefore an important -march option for 32 bit code. Therefore armv8a can not be used to imply aarch64. For example: - IT predication instruction with more than a single controlled 16 bit instruction, or an instruction that modifies PC is depreca...

...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 this). So after using AArch64TargetParser in options parsing in Clang,using "-march=aarch64" and "-march=arm64" are both valid. I saw Kevin has a different view on this in his submission:r213353. *+// RUN: %clang -target aarch64...

Motivation At the moment, when targeting armv7a, clang defaults to generate code as if -mcpu=cortex-a8 was specified. When targeting armv8a, it defaults to generate code as if -mcpu=cortex-a53 was specified. This leads to surprising code generation, by the compiler optimizing for a specific micro-architecture, whereas the intent from the user was probably to generate code that is "blended" for all the cores implementing the...

On 5 May 2016 at 13:01, Bradley Smith <Bradley.Smith at arm.com> wrote: > Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used > for specifying an architecture version to target whereas aarch64/arm64 don’t > convey any information to that effect, does it mean armv8a, armv8.1-a, etc? Hi Bradley, That's a good point. But also, what does "armv8a" mean? AArch64? AArch32? I guess we could use the triple (which has aarch64 or arm in it), but then it will need the triple or else we'll have a problem, since the current interpretation of "armv...

...t from our perspective. Thanks, Steve On Wed, May 31, 2017 at 5:57 AM, Kristof Beyls <Kristof.Beyls at arm.com<mailto:Kristof.Beyls at arm.com>> wrote: Motivation At the moment, when targeting armv7a, clang defaults to generate code as if -mcpu=cortex-a8 was specified. When targeting armv8a, it defaults to generate code as if -mcpu=cortex-a53 was specified. This leads to surprising code generation, by the compiler optimizing for a specific micro-architecture, whereas the intent from the user was probably to generate code that is "blended" for all the cores implementing the...

Hi On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc. --- $ llc -march=aarch64 -mattr=help 2>&1 | grep error $ #No Error $ llc -march=armv8a -mattr=help 2>&1 | grep error llc: error: invalid target 'armv8a'. $ clang -march=armv8a -E - < /dev/null 2>&1 | grep error $ #No Error $ clang -march=aarch64 -E - < /dev/null 2>&1 | grep error clang-4.0: error: the clang compiler does not support '-march=...

...t; Thank you very much! > > >> > Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is >> used >> > for specifying an architecture version to target whereas aarch64/arm64 >> don’t >> > convey any information to that effect, does it mean armv8a, armv8.1-a, >> etc? >> >> That's a good point. But also, what does "armv8a" mean? AArch64? AArch32? >> >> I guess we could use the triple (which has aarch64 or arm in it), but >> then it will need the triple or else we'll have a problem, since t...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/4e949495/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201507161639320_Y2AH3IN3.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/4e949495/attachment.gif>

Hello, We're evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int global_array[16]; int main(int argc, char **argv) { global_array[1] = 0; return global_array[argc + 16]; // BOOM } clang++ -O1 --target=aarch64-linux -march=armv8.5a+memtag...

...v at lists.llvm.org>> wrote: Hello, We’re evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int global_array[16]; int main(int argc, char **argv) { global_array[1] = 0; return global_array[argc + 16]; // BOOM } clang++ -O1 --target=aarch64-linux -march=armv8.5a+memtag...

From: Jia He <justin.he at arm.com> Date: Sat, 30 May 2020 09:38:28 +0800 > When client on the host tries to connect(SOCK_STREAM, O_NONBLOCK) to the > server on the guest, there will be a panic on a ThunderX2 (armv8a server): ... > The race condition is as follows: > Task1 Task2 > ===== ===== > __sock_release virtio_transport_recv_pkt > __vsock_release vsock_find_bound_socket (found sk) &gt...

...l, 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 running Ubuntu 13.04 in KVM, on ARM > running Fedora 18 on an Arndale board, and for Aarch64 by running > Open Embedded on the ARMv8A FVP model. > > Again the testing regime included running the klibc supplied tests, > as well as running the mksh test suite (with mksh both statically > compiled and linked against /lib/klibc-xxxxx.so). > > As always, any comments/critique/flames welcome. :-) > I applied th...

Hi Jia, thanks for the patch! I have some comments. On Fri, May 29, 2020 at 09:31:23PM +0800, Jia He wrote: > When client tries to connect(SOCK_STREAM) the server in the guest with NONBLOCK > mode, there will be a panic on a ThunderX2 (armv8a server): > [ 463.718844][ T5040] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 > [ 463.718848][ T5040] Mem abort info: > [ 463.718849][ T5040] ESR = 0x96000044 > [ 463.718852][ T5040] EC = 0x25: DABT (current EL), IL = 32 bits > [ 463.7...

On Fri, May 29, 2020 at 11:21:02PM +0800, Jia He wrote: > When client tries to connect(SOCK_STREAM) the server in the guest with > NONBLOCK mode, there will be a panic on a ThunderX2 (armv8a server): > [ 463.718844][ T5040] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 > [ 463.718848][ T5040] Mem abort info: > [ 463.718849][ T5040] ESR = 0x96000044 > [ 463.718852][ T5040] EC = 0x25: DABT (current EL), IL = 32 bits > [ 463.7...

...evaluating memory tagging (MTE) on some internal workloads. > > > > We noticed that stack variables are tagged by an instrumentation pass and > heap objects are handled by the allocator (Scudo). > > > > How about global variables? We tried a simple case using > -march=armv8a+memtag -fsanitize=memtag, but found no tagging: > > > > Are we missing anything or tagging globals is still in progress? > > > > *int global_array[16];* > > > > *int main(int argc, char **argv) {* > > * global_array[1] = 0;* > > * return global_arra...

...Spickett. mandatory features ================== >> Could you go into a bit more detail about mandatory features? I'm pretty sure people are using the extension functionality to turn off features which are technically mandatory according to the reference manual, like floating-point in armv8a. >> I'd be more comfortable if these weren't enabled by default, but were present in -Wall. It seems like a large portion of the architecturally invalid combinations have a technical reasoning. So I'd amend that point from: "- Emit a warning when a mandatory feature of the...

...nto 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 running Ubuntu 13.04 in KVM, on ARM running Fedora 18 on an Arndale board, and for Aarch64 by running Open Embedded on the ARMv8A FVP model. Again the testing regime included running the klibc supplied tests, as well as running the mksh test suite (with mksh both statically compiled and linked against /lib/klibc-xxxxx.so). As always, any comments/critique/flames welcome. :-) Cheers, -- Steve Steve Capper (3): syscalls...

Hi, Below is a document detailing changes we'd like to make to Clang/LLVM to improve the usability of the target options for ARM and AArch64. To keep things simple the proposed changes are listed at the start and you can find the supporting examples at the end of the document. I look forward to your feedback. Thanks, David Spickett. RFC New Clang target feature selection options for

...ned in the arm64 kernel. This series is to be applied against the latest klibc, just after 25a66fa README.klibc: update build information I have tested this series on x86_64 running Ubuntu 13.04 in KVM, on ARM running Fedora 18 on an Arndale board, and for Aarch64 by running Open Embedded on the ARMv8A FVP model. The testing regime included running the klibc supplied tests, as well as running the mksh test suite (with mksh both statically compiled and linked against /lib/klibc-xxxxx.so). Any comments/critique/flames welcome. Cheers, -- Steve Steve Capper (3): syscalls: Fixup some syscalls...