RFR: 8361582: AArch64: Some ConH values cannot be replicated with SVE [v4]

[Bhavana Kilambi]

On Wed, 13 Aug 2025 12:27:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> `Why not do something along these lines?`

I tried exactly that and it does generate a `mov` and a 'dup' for illegal immediates which is why I initially said I would put up a patch soon but I realised later that the `loadConH` node is also being generated somewhere above (most likely because the value it loads is required for the scalar `AddHF` nodes). This isn't ideal? As we wanted to get rid of the load from the constant pool in the first place, if I got you right?

> I don't understand.

Apologies for not being clear.
Another approach I thought was to directly modify the `loadConH` itself. 

`loadConH` is defined as - 

instruct loadConH(vRegF dst, immH con) %{
  match(Set dst con);
  format %{
    "ldrs $dst, [$constantaddress]\t# load from constant table: half float=$con\n\t"
  %}
  ins_encode %{
    __ ldrs(as_FloatRegister($dst$$reg), $constantaddress($con));
  %}
  ins_pipe(fp_load_constant_s);
%}


The destination register is an FPR. If we would want to modify this to generate a move to a scratch register instead (something similar to loadConI) then we would have to change the destination register to `iregI` which probably could be acceptable for autovectorization as we are replicating the value in a vector register anyway but for the scalar `AddHF` operation (the iterations that get peeled or the ones in pre/post loop which are not autovectorized), it would expect the value to be available in an FPR instead (the `h` register variant). So we might have to introduce a move from the GPR to an FPR. The reason why I felt I needed more time to investigate this. Please let me know your thoughts. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26589#issuecomment-3183788498