search for: armv8

...; > detectable like they have in cairo/pixman? For generic distributions > > it would nice to be able to be able to enable them as they offer > > decent performance improvements but have the code fall back on devices > > that don't support NEON. > Yep, adding support for ARMv8 is the final objective. I did not want to introduce too many changes in the first shot... and hence only introduced for ARMv7. In theory, most of the code (neon intrinsic code) in this patch should remain unchanged for ARMv8. Only the mechanism by which neon/asimd presence is detected during runtim...

...cairo/pixman? For generic distributions > >> > it would nice to be able to be able to enable them as they offer > >> > decent performance improvements but have the code fall back on devices > >> > that don't support NEON. > >> Yep, adding support for ARMv8 is the final objective. I did not want to introduce too many changes in the first shot... and hence only introduced for ARMv7. In theory, most of the code (neon intrinsic code) in this patch should remain unchanged for ARMv8. Only the mechanism by which neon/asimd presence is detected during runtim...

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co....

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-ma...

Hi there, I am Software product developer at Robert Bosch, Germany. We are using armv8 64bit targets for our development. We have the need to do the cross compiling for our target on windows. I have compiled clang 5.0 from the vcs git. I have tried compiling the code with following options set: clang.exe -target armv8 -fslp-vectorize-aggressive -mfpu=neon -mfloat-abi=hard -c test.c...

The clang-cmake-armv8-lld (linaro-toolchain owners) buildbot is timing out trying to run some timeout tests (Dan Liew author): Pass: http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/5672 Fail: http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/5673 Is there anything we can do to the buildbot?...

...evision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the week: buildername | was_red ---------------------------------------------------------+--------- libcxx-libcxxabi-libunwind-armv8-linux | 87:08:24 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions | 87:08:06 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 | 85:42:47 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu | 85:42:17 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a | 85...

...v7 run time > detectable like they have in cairo/pixman? For generic distributions > it would nice to be able to be able to enable them as they offer > decent performance improvements but have the code fall back on devices > that don't support NEON. > > Yep, adding support for ARMv8 is the final objective. I did not want to > introduce too many changes in the first shot... and hence only introduced > for ARMv7. In theory, most of the code (neon intrinsic code) in this patch > should remain unchanged for ARMv8. Only the mechanism by which neon/asimd > presence is de...

...the NEON optimisations on ARMv7 run time detectable like they have in cairo/pixman? For generic distributions it would nice to be able to be able to enable them as they offer decent performance improvements but have the code fall back on devices that don't support NEON. Yep, adding support for ARMv8 is the final objective. I did not want to introduce too many changes in the first shot... and hence only introduced for ARMv7. In theory, most of the code (neon intrinsic code) in this patch should remain unchanged for ARMv8. Only the mechanism by which neon/asimd presence is detected during runtim...

Hi all I think the ARMv8 isa is awesome, but just wondering if anyone is doing the work around llvm (besides Apple). I've heard rumors, but not sure how far along any of those projects are. Anyone who needs a Fortran compiler for it or is interested to work together ping me off list please. Thanks Christopher

...| 14:44:02 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std | 14:20:06 clang-lld-x86_64-2stage | 12:46:27 clang-with-thin-lto-ubuntu | 12:24:16 clang-cmake-armv7-full | 09:16:42 clang-cmake-armv8-selfhost-neon | 08:00:50 clang-cmake-x86_64-avx2-linux | 07:23:53 clang-cmake-aarch64-lld | 06:29:20 clang-cmake-thumbv7-full-sh | 06:24:29 clang-ppc64be-linux-lnt...

...e like they have in cairo/pixman? For generic distributions >> > it would nice to be able to be able to enable them as they offer >> > decent performance improvements but have the code fall back on devices >> > that don't support NEON. >> Yep, adding support for ARMv8 is the final objective. I did not want to introduce too many changes in the first shot... and hence only introduced for ARMv7. In theory, most of the code (neon intrinsic code) in this patch should remain unchanged for ARMv8. Only the mechanism by which neon/asimd presence is detected during runtim...

.... Werner Struth, Peter Tyroller -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Freitag, 3. Februar 2017 16:02 To: Haider Zeeshan (CC/ESM1) <Zeeshan.Haider at de.bosch.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Clang 5.0 support for armv8 64 bit with neon and auto vectorization On 3 February 2017 at 00:48, Haider Zeeshan (CC/ESM1) via llvm-dev <llvm-dev at lists.llvm.org> wrote: > clang.exe -target armv8 -fslp-vectorize-aggressive -mfpu=neon > -mfloat-abi=hard -c test.cpp Peter's advice is good (-mfpu and -mfloat...

...| 25:54:37 clang-cmake-thumbv7-full-sh | 22:37:58 clang-s390x-linux-multistage | 18:51:29 clang-cmake-aarch64-full | 17:33:43 clang-cmake-armv7-full | 15:46:51 clang-cmake-armv8-full | 15:14:20 clang-cmake-armv8-selfhost-neon | 14:46:53 sanitizer-ppc64le-linux | 14:18:30 clang-ppc64le-linux-multistage | 14:16:59 clang-cmake-aarch64-lld | 14:08:35 clang-s390x-...

...| 62:01:06 lldb-windows7-android | 57:13:19 clang-x86_64-linux-abi-test | 39:06:31 clang-with-lto-ubuntu | 31:07:33 clang-hexagon-elf | 30:03:02 clang-cmake-armv8-global-isel | 28:45:16 clang-cmake-armv8-full | 28:34:08 clang-cmake-armv7-selfhost | 28:28:58 clang-cmake-armv7-selfhost-neon | 28:27:16 clang-cmake-armv8-quick | 28:22:10 clang-cmake-...

...that took option 1 above. The command line is converted into a sequence of options and resolved by the LLVM backend. This means that Clang does not know exactly what will be enabled. It needs to know this to output the correct pre processor feature test macros. Consider this AArch64 march: -march=armv8.4-a+crypto+nosha2 The base arch is armv8.4-a, the crypto extension turns on AES/SHA2/SHA3/SM4. The nosha2 disables SHA2/SHA3 (since SHA3 is dependant on SHA2). Each of these features has an ACLE feature test macro, so Clang needs to know that nosha2 also disables SHA3. New Errors and Warnings ===...

...ks Galina The longest time each builder was red during the week: buildername | was_red ---------------------------------------------------------+--------- libcxx-libcxxabi-libunwind-aarch64-linux | 50:00:17 libcxx-libcxxabi-libunwind-armv8-linux | 47:23:17 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 40:53:18 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions | 40:53:18 clang-x86-windows-msvc2015 | 35:17:24 clang-cmake-armv8-full | 28...

...er later we might want to allow people to select which set of crypto extensions is added and we hit the same issue. (maybe you'd go with -mcrypto as an 'auto' and -mcrypto8.4-a etc, which is also ugly) The other option would be to allow -march without a base architecture. E.g. -march=armv8-a+crc -march=+crypto Or have them combine into some common set, which breaks existing behaviour: -march=armv8-a+crc -march=armv8.4-a+dsp -> -march=amv8-a+dsp+crc Which gets into a lot of issues around how you choose the set of features. Smallest subset to target the minimal core, or largest...

...n7 | 132:35:41 clang-x86-windows-msvc2015 | 88:37:04 llvm-clang-x86_64-expensive-checks-win | 63:58:55 clang-cmake-aarch64-full | 39:44:41 clang-with-thin-lto-windows | 12:19:51 clang-cmake-armv8-selfhost-neon | 12:00:59 clang-ppc64le-linux-multistage | 10:19:48 clang-cmake-armv7-global-isel | 10:19:13 clang-cmake-armv8-quick | 10:07:55 clang-s390x-linux-multistage | 09:51:31 clang-cmake-...

I know it's quick to ask, but when might support for the new Apple A7 processor appear in tree? Is the 64-bit architecture the same as ARMv8, or will we have a much bigger set of changes to contend with? Alex