RFR: 8248414: AArch64: Remove uses of long and unsigned long ints

David Holmes david.holmes at oracle.com
Wed Jul 8 07:29:25 UTC 2020


Hi Andrew,

On 27/06/2020 1:43 am, Andrew Haley wrote:
> All of the uses of long and unsigned long int should be replaced with
> more appropriate types. Where signed and unsigned 64-bit integers are
> required, use int64_t. Where pointers are required, use
> intptr_t. Where Java longs are required, use jlong.
> 
> http://cr.openjdk.java.net/~aph/8248414/

Generally okay but a few comments/queries below.

The change to add all the:

+ // This pattern is automatically generated from aarch64_ad.m4
+ // DO NOT EDIT ANYTHING IN THIS SECTION OF THE FILE

headers in the ad file made it much harder to spot the actual type changes.

src/hotspot/cpu/aarch64/assembler_aarch64.cpp

1704 bool Assembler::operand_valid_for_add_sub_immediate(*int64_t* imm) {
1705   bool shift = false;
1706   *julong* uimm = uabs(imm);

That seems a strange mix of C types and Java types

---

src/hotspot/cpu/aarch64/assembler_aarch64.hpp

    int64_t offset = (dest - pc()) >> 2;

It isn't immediately obvious to me why the offset should be signed in 
these cases whereas in other parts of the code offsets are unsigned. 
Just an observation though as you are not changing the signedness.

---

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp

  136         Instruction_aarch64::patch(branch + 4, 20, 5, 
(uint64_t)target >> 32);
  137          intptr_t dest = ((int64_t)target & 0xffffffffL) | 
((int64_t)branch & 0xffff00000000L);
  138         intptr_t pc_page = (int64_t)branch >> 12;
  139         intptr_t adr_page = (int64_t)dest >> 12;

There's an extra leading space on line 137.

It's not obvious to me why the casts are to int64_t and the variable 
assigned to is intptr_t, especially when just up from this we have:

96       uint64_t dest = (uint64_t)target;
97       uint64_t pc_page = (uint64_t)branch >> 12;
98       uint64_t adr_page = (uint64_t)target >> 12;

Also should those constants be LL for good measure?

1720   uint64_t mask = (1ul << shift) - 1;

Making the mask 64-bit instead of 32-bit seems like a functional change. 
Also the 1ul should be 1ull shouldn't it?

4352       = (target & 0xffffffffUL) | ((uint64_t)pc() & 0xffff00000000UL);

Should those constants be ULL? (they seem oddly expressed for 64-bit 
constants)

---

src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp

Not obvious why the constants should be Java types.

---

src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp

Not obvious why the constants should be Java types.

! // *              jlong double t,w,r_head, r_tail;

The "long" is part of "long double" and shouldn't have been changed to 
jlong.

---

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp

!     // However to make thing extra confusing. Because we can fit a 
jlong/double in
!           // jlong/double in gpr

I think it was clear from context that "long" was referring to the Java 
type. If you wanted to be sure I'd suggest writing "Java long/double".

---

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

montgomery_multiply: not at all clear why these should be julong

---

Thanks,
David
-----


More information about the hotspot-dev mailing list