RFR: 8276563: Undefined Behaviour in class Assembler [v3]
Andrew Haley
aph at openjdk.java.net
Sat Nov 13 09:46:36 UTC 2021
On Sat, 13 Nov 2021 07:43:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Re-establish the FloatRegister::successor() hack.
>
> src/hotspot/cpu/aarch64/register_aarch64.hpp line 255:
>
>> 253: enum {
>> 254: number_of_registers = 16,
>> 255: number_of_declared_registers = 16,
>
> Is there a semantic difference between number of registers and declared registers for float and P registers? Otherwise, having two constants for the same thing makes the code less clear and maybe more error prone.
Perhaps, but I'm trying to do something really general. There is _sometimes_ a difference between the number of physical registers and the number of named registers, and that's what I'm trying to capture here.
> src/hotspot/share/asm/register.hpp line 62:
>
>> 60: #else // USE_POINTERS_TO_REGISTER_IMPL_ARRAY
>> 61:
>> 62: #define REGISTER_IMPL_DECLARATION(type, impl_type) \
>
> nit: align backslashes?
You've got a point. I'll have another look.
> src/hotspot/share/asm/register.hpp line 64:
>
>> 62: #define REGISTER_IMPL_DECLARATION(type, impl_type) \
>> 63: inline const type as_ ## type(int encoding) { \
>> 64: assert(encoding <= impl_type::number_of_declared_registers, "invalid register"); \
>
> assert for >= -1 too?
OK.
> src/hotspot/share/asm/register.hpp line 87:
>
>> 85: // OS-specific way.
>> 86: #ifdef __GNUC__
>> 87: #define INTERNAL_VISIBILITY __attribute__ ((visibility ("internal")))
>
> I try to understand this, is this to allow other object files to see these symbols while preventing them from being exported from the libjvm?
Preventing them from being _redefined_ by other shared libraries. Without this, every time you load the address of `all_Registers` you load from the Global Offset Table, rather than using an immediate operand.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6280
More information about the hotspot-compiler-dev
mailing list