On 03/01/2016 04:11 PM, Ulrich Weigand wrote:
> I wrote:
>> Andreas Krebbel wrote:
>>
>>> +; vec_set is supposed to *modify* an existing vector so operand 0 is
>>> +; duplicated as input operand.
>>> +(define_expand "vec_set<mode>"
>>> +  [(set (match_operand:V                    0 "register_operand"           
>>>    "")
>>> +   (unspec:V [(match_operand:<non_vec> 1 "general_operand"               
>>> "")
>>> +              (match_operand:SI        2 "shift_count_or_setmem_operand" 
>>> "")
>>
>> This is probably only cosmetic, but should we use nonmemory_operand here
>> instead of shift_count_or_setmem_operand (just like everywhere else now)?
>>
>>> +(define_expand "vec_extract<mode>"
>>> +  [(set (match_operand:<non_vec> 0 "nonimmediate_operand" "")
>>> +   (unspec:<non_vec> [(match_operand:V  1 "register_operand" "")
>>> +                      (match_operand:SI 2 "shift_count_or_setmem_operand" 
>>> "")]
>>
>> Likewise.
> 
> I just noticed that there are two more UNSPEC_VEC_SET expanders
> in vx-builtins.md.  I guess those should be likewise changed:
> 
> (define_expand "vec_insert<mode>"
>   [(set (match_operand:V_HW                    0 "register_operand" "")
>         (unspec:V_HW [(match_operand:<non_vec> 2 "register_operand" "")
>                       (match_operand:SI        3 
> "shift_count_or_setmem_operand" "")
>                       (match_operand:V_HW      1 "register_operand" "")]
>                      UNSPEC_VEC_SET))]
>   "TARGET_VX"
>   "")
> 
> (define_expand "vec_promote<mode>"
>   [(set (match_operand:V_HW                    0 "register_operand" "")
>         (unspec:V_HW [(match_operand:<non_vec> 1 "register_operand" "")
>                       (match_operand:SI        2 
> "shift_count_or_setmem_operand" "")
>                       (match_dup 0)]
>                      UNSPEC_VEC_SET))]
>   "TARGET_VX"
>   "")
> 
> Then the only remaining users of shift_count_or_setmem_operand are the
> actual setmem patterns (so maybe the predicate can be renamed to
> "setmem_operand") :-)

Yes. We probably should also try to get rid of s390_decompose_shift_count. 
Perhaps it can be merged
into decompose_address as a special case?! At least it should get a new name as 
well. I'll move
these changes into the next development cycle. I've caused enough stage4 
breakage for today ;)

Thanks for reviewing the patches!

Bye,

-Andreas-

Reply via email to