Hi! On Fri, Jul 19, 2019 at 10:21:06AM +0800, Kewen.Lin wrote: > on 2019/7/19 上午3:48, Segher Boessenkool wrote: > > On Thu, Jul 18, 2019 at 01:44:36PM +0800, Kewen.Lin wrote: > >> on 2019/7/17 下午9:40, Segher Boessenkool wrote: > >>> 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.
This is wrong. I don't know why I thought this for a while. There shouldn't be any rotatert in anything that goes through recog, but that is everything *except* define_expand. So define_insn, define_split, define_peephole, define_peephole2 (and define_insn_and_split, which is just syntactic sugar). > 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. You only had one in a define_expand. That is fine, that pattern is never recognised against. HAVE_rotatert means that something somewhere will recognise rotatert RTL insns; if it isn't set, it doesn't make sense to ever create them, because they will never match. > although I can see rotatert in insn like below, it seems fine in note? Sure, many things are allowed in notes that can never show up in RTL proper. So, this approach will work fine, and not be too bad. Could you do a new patch with it? It's simple to do, and even if the generic thing will happen eventually, this is a nice stepping stone for that. Thanks, and sorry for the confusion, Segher
