SPARCv9 assembler pack: refine CPU detection on Linux, fix for "unaligned
[oweals/openssl.git] / crypto / sha / asm / sha1-sparcv9.pl
index 9f2d15951433e97adc4147611ac312d340e0051e..5c161cecd696c56ffcf9d0a35cc818dcbab63f6b 100644 (file)
@@ -8,13 +8,15 @@
 # ====================================================================
 
 # Performance improvement is not really impressive on pre-T1 CPU: +8%
-# over Sun C and +25% over gcc [3.3]. While on T1, ... And there
-# is a gimmick. X[16] vector is packed to 8 64-bit registers and as
-# result nothing is spilled on stack. In addition input data is loaded
-# in compact instruction sequence, thus minimizing the window when the
-# code is subject to [inter-thread] cache-thrashing hazard. The goal
-# is to ensure scalability on UltraSPARC T1, or rather to avoid decay
-# when amount of active threads exceeds the number of physical cores.
+# over Sun C and +25% over gcc [3.3]. While on T1, a.k.a. Niagara, it
+# turned to be 40% faster than 64-bit code generated by Sun C 5.8 and
+# >2x than 64-bit code generated by gcc 3.4. And there is a gimmick.
+# X[16] vector is packed to 8 64-bit registers and as result nothing
+# is spilled on stack. In addition input data is loaded in compact
+# instruction sequence, thus minimizing the window when the code is
+# subject to [inter-thread] cache-thrashing hazard. The goal is to
+# ensure scalability on UltraSPARC T1, or rather to avoid decay when
+# amount of active threads exceeds the number of physical cores.
 
 $bits=32;
 for (@ARGV)    { $bits=64 if (/\-m64/ || /\-xarch\=v9/); }
@@ -274,6 +276,7 @@ $code.=<<___;
 .type  sha1_block_data_order,#function
 .size  sha1_block_data_order,(.-sha1_block_data_order)
 .asciz "SHA1 block transform for SPARCv9, CRYPTOGAMS by <appro\@openssl.org>"
+.align 4
 ___
 
 $code =~ s/\`([^\`]*)\`/eval $1/gem;