RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL

dean.long at oracle.com dean.long at oracle.com
Fri May 17 06:34:48 UTC 2019


Looks good to me too.

dl

On 5/16/19 5:24 AM, David Holmes wrote:
> My apologies Boris your webrev is correct.
>
> David
>
> On 16/05/2019 7:27 pm, David Holmes wrote:
>> Hi Boris,
>>
>> Just a note that your webrevs should be against the mainline code, 
>> not incremental from your previous proposed patch. (Though you can 
>> also provide an incremental webrev if you desire.)
>>
>> Thanks,
>> David
>>
>> On 16/05/2019 6:37 pm, Boris Ulasevich wrote:
>>>  > The default value is also too big (64) so your code would handle 
>>> this
>>>  > case anyway.
>>>
>>>
>>> On 16.05.2019 10:19, David Holmes wrote:
>>>> Hi Boris,
>>>>
>>>> On 15/05/2019 11:13 pm, Boris Ulasevich wrote:
>>>>> Hi David,
>>>>>
>>>>> On 15.05.2019 15:39, David Holmes wrote:
>>>>>> Hi Boris,
>>>>>>
>>>>>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Thanks for review! I added a warning and fixed the drop back value:
>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02
>>>>>>
>>>>>> With that change this code is pointless:
>>>>>>
>>>>>>   274   if (FLAG_IS_DEFAULT(MaxVectorSize)) {
>>>>>>   275     // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8);
>>>>>>   276     // SIMD/NEON can use 16, but default is 8 because 
>>>>>> currently
>>>>>>   277     // larger than 8 will disable instruction scheduling
>>>>>>   278     FLAG_SET_DEFAULT(MaxVectorSize, 8);
>>>>>>   279   }
>>>>>>
>>>>>> as it will be handled by your new code.
>>>>>
>>>>> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is 
>>>>> specified while the new code sets 8/16 when the specified size is 
>>>>> too big. I think these two blocks of code live together quite well :)
>>>>
>>>> The default value is also too big (64) so your code would handle 
>>>> this case anyway. But as Dean notes the warning should only be 
>>>> issued when the user explicitly sets the value.
>>>
>>> I see. I like your proposal. It is just more reasonable code.
>>> Thanks to you and Dean!
>>>
>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03
>>>
>>>> So I think your change is better applied as an else clause to the 
>>>> existing code:
>>>>
>>>>   if (FLAG_IS_DEFAULT(MaxVectorSize)) {
>>>>     // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8);
>>>>     // SIMD/NEON can use 16, but default is 8 because currently
>>>>     // larger than 8 will disable instruction scheduling
>>>>     FLAG_SET_DEFAULT(MaxVectorSize, 8);
>>>> ! } else {
>>>> +   int max_vector_size = has_simd() ? 16 : 8;
>>>> +   if (MaxVectorSize > max_vector_size) {
>>>> +     warning("MaxVectorSize must be at most %i on this platform", 
>>>> max_vector_size);
>>>> +     FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size);
>>>> +   }
>>>> + }
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> regards,
>>>>>>> Boris
>>>>>>>
>>>>>>> On 15.05.2019 4:16, David Holmes wrote:
>>>>>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote:
>>>>>>>>> Looks fine, but you might want to print a warning if you 
>>>>>>>>> override the user's choice.
>>>>>>>>
>>>>>>>> I would normally agree, but in this case the following code 
>>>>>>>> will already silently overwrite the user's choice in some cases:
>>>>>>>>
>>>>>>>>   281   if (MaxVectorSize > 16) {
>>>>>>>>   282     FLAG_SET_DEFAULT(MaxVectorSize, 8);
>>>>>>>>   283   }
>>>>>>>>
>>>>>>>> and I find it odd that it drops it back to 8 rather than taking 
>>>>>>>> the upper-limit of 16.
>>>>>>>>
>>>>>>>> To me the first problem here is that MaxVectorSize should be a 
>>>>>>>> pd_global so each platform can just set the right default to 
>>>>>>>> begin with, and set a correct allowed range for that platform. 
>>>>>>>> In fact with a constraint function it could even incorporate 
>>>>>>>> the has_simd() check. But that's getting a bit beyond the 
>>>>>>>> current fix.
>>>>>>>>
>>>>>>>> I can't see any non-convoluted way to print a warning under all 
>>>>>>>> the right circumstances, so I'll leave it to Boris to decide 
>>>>>>>> what to do here. I don't think a warning is essential.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> dl
>>>>>>>>>
>>>>>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review a simple change to prevent VLD1/VST1 
>>>>>>>>>> instructions generation on ARM32 processor without SIMD 
>>>>>>>>>> support. The change overrides MaxVectorSize option set up by 
>>>>>>>>>> user to a value acceptable by the hardware.
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656
>>>>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Boris
>>>>>>>>>



More information about the hotspot-dev mailing list