[External] : JDK-8216554

[Suchismith Roy]

Hi All
I  am working on JDK-8216554 — optimizing constant loading on PPC64 by replacing the two-instruction sequence (ADDIS + LD) with a single LD instruction when the method TOC offset fits in a 16-bit signed displacement.

Background:

Currently on PPC64, all long constant loads in C2-compiled code go through a two-node hi/lo pair (loadConL_hi + loadConL_lo), emitting ADDIS + LD regardless of the constant pool offset. This is because the decision was hardcoded as:

  const bool large_constant_pool = true; // TODO: PPC port C->cfg()->_consts_size > 4000;

The TODO was never implemented.
 The intent was to check the constant pool size at postalloc time and choose between a single-node (small) or two-node (large) path. However, the constant pool size is not available at postalloc — constant_table().size() returns 0 on PPC64 because the platform uses its own TOC-based constant pool via MacroAssembler::long_constant(), bypassing the generic C2 ConstantTable.

Approach:

Thanks to Dean Long's suggestion of creating a single smart node that decides its instruction encoding at emit time, I create a single loadConLNode at postalloc and defer the instruction selection to the emit stage. During emit, the method TOC offset (toc_offset) for each constant is known and stable, so the decision is made per-constant:

  int toc_offset = __ offset_to_method_toc(const_toc_addr);

  if (Assembler::is_simm(toc_offset, 16)) {
      // Small path: single LD + NOP (8 bytes)
      __ ld(dst, toc_offset, toc_reg);
      __ nop();
  } else {
      // Large path: ADDIS + LD (8 bytes)
      __ addis(dst, toc_reg, largeoffset_si16_si16_hi(toc_offset));
      __ ld(dst, largeoffset_si16_si16_lo(toc_offset), dst);
  }

Both paths emit exactly 8 bytes, matching the scratch emit reservation. The NOP in the small path maintains size consistency.

One thing I would like confirmation on: is it correct to rely on the method TOC offset (toc_offset) at emit time for the instruction selection?

I want to confirm there are no edge cases where this assumption breaks.

I would appreciate any feedback on this approach.

Thanks,
Suchismith Roy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20260227/4fc2774f/attachment.htm>