[RFC] imgrel/imagerel operator from the clang integrated assembler and the Microsoft assembler

[Jan Beulich]

On 08.11.2024 14:47, Julian Waters wrote:
> In this case I think there might be a bit too much context - The Java Short
> Vector Math Library is enormous and spans tens of thousands of lines of
> assembly. An example of imagerel being used in it in the surrounding
> context is
> https://github.com/openjdk/jdk/blob/7d6a2f3740bf42652bdf05bb922d1f2b2ae60d6a/src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S#L98

Seeing the full file is certainly useful. It raises the question though why
__jsvml_dtanh_ha_data_internal would need accessing both as normal symbol
and via @imgrel. To take an example, the original

	vmovupd   xmm10, XMMWORD PTR [imagerel(__jsvml_dtanh_ha_data_internal)+2704+rdx+rcx]

could apparently be replaced by

	vmovupd   xmm10, XMMWORD PTR [__jsvml_dtanh_ha_data_internal+2704+rcx]

(seeing that RDX holds __ImageBase). Question being why that's not done. It
would even reduce the resulting binary size, for no longer requiring a SIB
byte.

With all the literal numbers in there it also looks unlikely to be a human-
maintained file. Is it perhaps rather machine-generated (in which case the
way it is being generated could be adjusted)?

> Does the .reloc example rely on the instruction bytes being assembled into
> a certain location (In this case, 4 bytes behind the current location)?

The example certainly makes assumptions on how insns are being encoded. (If
that doesn't answer your question, I'm afraid you need to rephrase the
question, as I don't really understand specifically the part in
parentheses.)

> That might be rather brittle and easy to break if the instruction just so
> happens to have the relocation itself in a different position as the example

Use of .reloc definitely requires a fair amount of care. There should be no
other relocation at the same location in code; it's the programmer who has to
guarantee that.

Jan