Currently, floating point constants are loaded from the nmethod constant pool
using the address of the constant directly. For sparc64, this means materializing
a 64-bit address in a register using up to 6 instructions and then dereferencing it.
Each constant has a unique address, so each load must use a different instruction
sequence. It would be nice to avoid this somehow.

One way to do this, which amounts to using pc-relative addressing, is to change the compiler IR to reference items in the nmethod constant pool via base + offset rather
than directly. That way, the base address can be CSE'ed by the compiler and stored
in a register, thus avoiding more than one 64-bit address materialization. The base address can be obtained by making it a relocatable constant or by materializing the nmethod address (or a proxy such as the method entry point) into the method entry IR.

In addition to floating point constants, 64-bit address constants (e.g., oops)
could be stored in the nmethod constant pool. On some platforms, such as CMT,
a load might be the same speed or faster than issuing 6 instructions. Depends on
the tradeoff between I$ and D$ occupancy and how much fragmentation might result
in the D$. We'd expect not much, because D$ line size is 16 bytes and it's unlikely
the program would not use the second half of the line to store something else useful
(like another constant).

Another benefit of storing 64-bit address constants in the nmethod constant pool is
that patching them (oops must be patched when gc moves the referenced object) is much
easier, especially in cases where they must be patched atomically.