on 2019/7/19 上午3:48, Segher Boessenkool wrote:
> On Thu, Jul 18, 2019 at 01:44:36PM +0800, Kewen.Lin wrote:
>> Hi Segher,
>>
>> on 2019/7/17 下午9:40, Segher Boessenkool wrote:
>>> Hi Kewen,
>>>
>>> On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin wrote:
>>>> Regression testing just launched, is it OK for trunk if it's bootstrapped
>>>> and regresstested on powerpc64le-unknown-linux-gnu?
>>>
>>>> +;; Expanders for rotatert to make use of vrotl
>>>> +(define_expand "vrotr<mode>3"
>>>> + [(set (match_operand:VEC_I 0 "vint_operand")
>>>> + (rotatert:VEC_I (match_operand:VEC_I 1 "vint_operand")
>>>> + (match_operand:VEC_I 2 "vint_reg_or_const_vector")))]
>>>
>>> Having any rotatert in a define_expand or define_insn will regress.
>>>
>>> So, nope, sorry.
>>
>> Thanks for clarifying! Since regression testing passed on powerpc64le,I'd
>> like to double confirm the meaning of "regress", does it mean it's
>> a regression from design view? Is it specific to rotatert and its
>> related one like vrotr?
>
> You will get HAVE_rotatert defined in insn-config.h if you do this patch,
> and then simplify-rtx.c will not work correctly, generating rotatert by
> an immediate, which we have no instructions for.
>
> This might be masked because many of our rl*.c tests already fail because
> of other changes, I should fix that :-/
>
Hi Segher,
Thanks for further explanation! Sorry that, but I didn't find this
HAVE_rotatert definition. I guess it's due to the preparation is always
"DONE"? Then it doesn't really generate rotatert.
although I can see rotatert in insn like below, it seems fine in note?
(insn 10 9 11 4 (set (reg:V4SI 122 [ vect__2.7 ])
(rotate:V4SI (reg:V4SI 121 [ vect__1.6 ])
(reg:V4SI 124))) "t.c":17:28 1596 {*altivec_vrlw}
(expr_list:REG_EQUAL (rotatert:V4SI (reg:V4SI 121 [ vect__1.6 ])
(const_vector:V4SI [
(const_int 8 [0x8]) repeated x4
]))
(nil)))
Thanks,
Kewen
