Update copyright year

[thirdparty/openssl.git] / doc / man3 / OPENSSL_ia32cap.pod

diff --git a/doc/man3/OPENSSL_ia32cap.pod b/doc/man3/OPENSSL_ia32cap.pod
index 6c2d4b78ef79fd0a258e584e350577450449fa0b..e529c6c64f4e109c28072d53a79ae02c1edcc7dc 100644 (file)
--- a/doc/man3/OPENSSL_ia32cap.pod
+++ b/doc/man3/OPENSSL_ia32cap.pod
@@ -69,10 +69,10 @@ executed on SSE2 capable CPU, but under control of OS that does not
 enable XMM registers. Historically address of the capability vector copy
 was exposed to application through OPENSSL_ia32cap_loc(), but not
 anymore. Now the only way to affect the capability detection is to set
-OPENSSL_ia32cap environment variable prior target application start. To
-give a specific example, on Intel P4 processor 'env
-OPENSSL_ia32cap=0x16980010 apps/openssl', or better yet 'env
-OPENSSL_ia32cap=~0x1000000 apps/openssl' would achieve the desired
+B<OPENSSL_ia32cap> environment variable prior target application start. To
+give a specific example, on Intel P4 processor
+C<env OPENSSL_ia32cap=0x16980010 apps/openssl>, or better yet
+C<env OPENSSL_ia32cap=~0x1000000 apps/openssl> would achieve the desired
 effect. Alternatively you can reconfigure the toolkit with no-sse2
 option and recompile.
 
@@ -102,7 +102,7 @@ and RORX;
 =item bit #64+19 denoting availability of ADCX and ADOX instructions;
 
 =item bit #64+21 denoting availability of VPMADD52[LH]UQ instructions,
-a.k.a. AVX512IFMA extension;
+aka AVX512IFMA extension;
 
 =item bit #64+29 denoting availability of SHA extension;
 
@@ -116,48 +116,18 @@ a.k.a. AVX512IFMA extension;
 
 =back
 
-To control this extended capability word use ':' as delimiter when
-setting up OPENSSL_ia32cap environment variable. For example assigning
-':~0x20' would disable AVX2 code paths, and ':0' - all post-AVX
+To control this extended capability word use C<:> as delimiter when
+setting up B<OPENSSL_ia32cap> environment variable. For example assigning
+C<:~0x20> would disable AVX2 code paths, and C<:0> - all post-AVX
 extensions.
 
-It should be noted that whether or not some of the most "fancy"
-extension code paths are actually assembled depends on current assembler
-version. Base minimum of AES-NI/PCLMULQDQ, SSSE3 and SHA extension code
-paths are always assembled. Apart from that, minimum assembler version
-requirements are summarized in below table:
-
-   Extension   | GNU as | nasm   | llvm
-   ------------+--------+--------+--------
-   AVX         | 2.19   | 2.09   | 3.0
-   AVX2        | 2.22   | 2.10   | 3.1
-   ADCX/ADOX   | 2.23   | 2.10   | 3.3
-   AVX512      | 2.25   | 2.11.8 | see NOTES
-   AVX512IFMA  | 2.26   | 2.11.8 | see NOTES
-   VAES        | 2.30   | 2.13.3 |
-
-=head1 NOTES
-
-Even though AVX512 support was implemented in llvm 3.6, compilation of
-assembly modules apparently requires explicit -march flag. But then
-compiler generates processor-specific code, which in turn contradicts
-the mere idea of run-time switch execution facilitated by the variable
-in question. Till the limitation is lifted, it's possible to work around
-the problem by making build procedure use following script:
-
-   #!/bin/sh
-   exec clang -no-integrated-as "$@"
-
-instead of real clang. In which case it doesn't matter which clang
-version is used, as it is GNU assembler version that will be checked.
-
 =head1 RETURN VALUES
 
 Not available.
 
 =head1 COPYRIGHT
 
-Copyright 2004-2018 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2004-2021 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy