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

[Bhavana Kilambi]

On Wed, 13 Aug 2025 13:01:57 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!
>
>> 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`
> 
> This is the part I don't understand. Why would you have to change the destination register to `iregI`? I wouldn't.
> 
> 
> instruct loadConH(vRegF dst, immH con) %{
>   match(Set dst con);
>   format %{
>     "something"
>   %}
>   ins_encode %{
>     __ movw(rscratch1, $con$$constant);
>     __ fmovs($dst$$reg, rscratch1);
>   %}
>  ```

Hi @theRealAph could I please request for a re-review? Thanks! I would like to push this to JDK-25u as well as mainline.

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

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