RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v14]

Volodymyr Paprotski duke at openjdk.org
Mon Nov 14 17:50:47 UTC 2022


On Fri, 11 Nov 2022 20:46:57 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> It's not specific to `andq`: there's a huge `#ifdef` block around the definitions in `assembler_x86.hpp` (lines 12201 - 13773; and there's even a nested `#ifdef _LP64` (lines 13515-13585)!) , but declarations aren't guarded by `#ifdef _LP64`.
>
> Yeah, just got to about the same conclusion by looking at the preprocessor `-E` output.. its declared in the header, but not defined in the 'cpp' file.. One would think that that's a compile error, but its been more then a decade since I looked at the C++ spec; 'C++ compiler is always right'.

Don't know that there is anything else for me to do here? `assembler_x86.hpp` `#ifdef _LP64` macros were there before (and it not 'that wrong' or if a better/clean fix exists). `macroAssembler_x86.hpp` has to mirror that with `andq`.

(Just going through all the comments, making sure they have been addressed.) 

PS: In general I get worried about having macros changing object layout, but that's 'water under the bridge' and 64-bit seems big enough reason to have different layout. But its always 'entertaining debugging session' when offset of `a.f` is different in `a.o` and `b.o`, because somebody forgot to define same macros for `b.c` compile command as for `a.c`..

-------------

PR: https://git.openjdk.org/jdk/pull/10582


More information about the security-dev mailing list