Request for reviews (S): 7200264: 7192963 changes disabled shift vectors

[Vladimir Kozlov]

After some discussion and more thinking I decided to remove my hack, method 
Matcher::vector_shift_cnt_in_vreg(), from these changes and do proper fix in 
separate changes. I don't like such platform special code in general code. New 
implementation will use new ideal (vector?) node for vector shift count so that 
each platform will have own mach node implementation for it.

Thanks,
Vladimir

Vladimir Kozlov wrote:
> Thanks, Vladimir
> 
> Vladimir Ivanov wrote:
>> Vladimir,
>>
>> Looks great! =)
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 9/25/12 5:42 AM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/7200264/webrev.01
>>>
>>> I added test.
>>>
>>> And I also added new method Matcher::vector_shift_cnt_in_vreg() to move
>>> vector shift count into vector register only on x86 because other
>>> platforms may support it in general register.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Vladimir Ivanov wrote:
>>>> Vladimir,
>>>>
>>>> What do you think about adding a simple test (parse output for
>>>> TestIntVect) to check that shift vectors are actually used?
>>>>
>>>> Otherwise, looks good to me.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 09/22/12 02:32, Vladimir Kozlov wrote:
>>>>> http://cr.openjdk.java.net/~kvn/7200264/webrev
>>>>>
>>>>> 7192963 changes disabled shift vectors when count is vector. By 
>>>>> accident
>>>>> it also disable supported shift vectors when count is loop invariant
>>>>> value.
>>>>>
>>>>> Replaced is_vector_use() call with explicit check for vector shift's
>>>>> count (member of some pack).
>>>>>
>>>>> Also fixed the check in main (first) loop in profitable() method to 
>>>>> not
>>>>> check for scalar promotion case (inputs are the same) which is already
>>>>> done in is_vector_use(). Otherwise cases when input vectors have
>>>>> different size or alignment may pass this check  (currently they don't
>>>>> because constructed packs have different elements (ideal nodes) - 
>>>>> packs
>>>>> are not constructed for the same inputs (scalar promotion case)).
>>>>>
>>>>> Thanks,
>>>>> Vladimir