[vector] unsigned operations

[Paul Sandoz]

> On Apr 5, 2021, at 4:57 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 5, 2021, at 12:57 PM, Viswanathan, Sandhya <sandhya.viswanathan at intel.com> wrote:
>> 
>> Hi Paul,
>> 
>> Your changes look good to me and it could be committed as is.
>> 
>> On the specific questions you asked on next steps for hotspot changes, my thoughts are as follows:
>> 1) Do we need to enhance arch_supports_vector to check if it supports unsigned comparisons? It might make it easier initially to add support separately for different CPU architectures.
>>    All the architectures should support vector unsigned comparison as it is needed by other languages.
>>    For the time being, we could add a function Matcher::supports_unsigned_vector_comparison() which could return false for an architecture till the backend work is completed for it.
> 
> +1
> 
>> 2) I suspect I will need to push the unsigned bit into VectorMaskCmpNode and then, at least on x86, update the matching vector compare instruction methods to pass the signed bit to the instruction macros, which are updated accordingly.
>>   Yes, you could pass the cond values as is to the IR node and let the x86.ad file handle it.
>>   e.g.  booltest_pred_to_comparison_pred() in x86.ad will need to be updated to handle the additional cond codes and rest should work.
> 
> +1
> 
> In the Java code, I don’t see the value of splitting the
> comparison switch statements apart into one switch
> for signed and one switch for unsigned.  (Is there a
> performance benefit?  I doubt it.)  It would be cleaner
> I think to create and use constants BT_u{lt,le,gt,ge}
> with unified switches.  The FP versions can just omit
> the extra four cases.
> 

Yes, that would be much better. I lost focus trying to avoid adding constants that were not part of enum mask of BoolTest. I will add such constants to VectorSupport, and ensure in comments/names that there is a difference.  

Paul.