search for: asimd

...def A57UnitV : ProcResGroup<[A57UnitX, A57UnitW]>; // Type V micro-ops } ``` According the Cortex-A57 software optimization manual, Cortex-A57 has 8 function units in the backend, - Branch(B) - Integer 0(I0) - Integer 1(I1) - Integer Muti-Cycle(M) - Load(L) - Store(S) - FP/ASIMD 0(F0) - FP/ASIMD 1(F1) So I think `A57UnitW` and `A57UnitX` should be the TableGen records defining pipeline F0 and F1, respectively. So `A57UnitW` and `A57UnitX` together compose a `ProcResGroup`, `A57UnitV`, which can execute a 128bit ASIMD floating point operation, such as FMLA(Q-form), i...

...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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. > > And yes, this patch also supports runtime detection of neon. Actuall...

...; >> 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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. > >> > >> And yes, this patch also supports runtime detection...

>> >> a. Simplest use case to validate this optimization for correctness. >> >> b. Simplest use case to validate this optimization for performance. >> >> >> >> Would prefer something like opusdec that can be executed on command >> >> line. >> > >> > >> > The easiest thing to use is probably opus_demo (opusdec

.... >> 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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. >> >> And yes, this patch also supports runtime detection of 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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. >> >> And yes, this patch also supports runtime detection of neon....

...aarch64*) the configure.ac code should be much smaller as we can make valid assumption that NEON will be supported... so as Jonathan Lennox suggested earlier, most of these flags can be hardcoded..... even run time checks can be disabled as ARMv8 cpu in aarch64 mode is guaranteed to have NEON/ASIMD. > >> AS_GCC_INLINE_ASSEMBLY( >> [inline_optimization="ARM"], >> [inline_optimization="disabled"] >> @@ -212,6 +211,35 @@ AS_IF([test x"${enable_asm}" = x"yes"],[ >>...

...port 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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. And yes, this patch also supports runtime detection of neon. Actually, most of...

...port 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 runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized. And yes, this patch also supports runtime detection of neon. Actually, most of...

...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 runtime and the flags used during compile are > the only ones that should change. I will work on this once this patch gets > reviewed and accepted. I made sure these changes are fairly localized. > > And yes, this patch also supports runtime detection of...

...lity Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Vulnerable Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm crc32 cpuid $ uname -a Linux host1 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux The host `apt` packages (dpkg) are up-to-date. I suspect this bug is specific to this Debian-derived distribution and/or ARM architecture. -- You are receiving this ma...