This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH V2, rs6000] Support vrotr<mode>3 for int vector types

Hi Segher,

Thanks for the clarification! 

Compared with the previous one, this add vrl<mode>_and define_insn(s)
for explicit AND (truncation) as Jakub's suggestion.

Bootstrapped and regtested on powerpc64le-unknown-linux-gnu, is it ok
for trunk?



2019-07-23  Kewen Lin  <>

	* config/rs6000/ (vint_reg_or_const_vector): New predicate.
	* config/rs6000/ (vrotr<mode>3): New define_expand.
	* config/rs6000/ (vrl<mode>_and): New define_insns.


2019-07-23  Kewen Lin  <>

	* New test.
	* New test.

on 2019/7/19 下午11:06, Segher Boessenkool wrote:
> 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

Attachment: expand.diff
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]