RegMask uses arrays of 32-bit ints to store its' values, which means most operations happen in more steps than they have to.
I did a proof-of-concept by rewriting this using uint64_t, which shows a 5% reduction in instructions and branches from C2 compilations:
https://github.com/openjdk/jdk/compare/master...cl4es:c2_opts
To not penalize 32-bit builds/platforms that should probably be written using uintptr_t or similar. At least measure and verify that the uint64_t implementation doesn't measurably hurt 32-bit builds.
I did a proof-of-concept by rewriting this using uint64_t, which shows a 5% reduction in instructions and branches from C2 compilations:
https://github.com/openjdk/jdk/compare/master...cl4es:c2_opts
To not penalize 32-bit builds/platforms that should probably be written using uintptr_t or similar. At least measure and verify that the uint64_t implementation doesn't measurably hurt 32-bit builds.
- relates to
-
JDK-8256166 [C2] Registers get confused on Big Endian after 8221404
-
- Resolved
-
-
JDK-8257221 C2: RegMask::is_bound_set split set handling broken since JDK-8221404
-
- Closed
-