Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Segher Boessenkool
On Thu, Jul 18, 2019 at 09:01:13AM +0200, Jakub Jelinek wrote: > On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote: > > I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED > > for rotates? Not all immediates are valid of course, but that is a > > separate issue

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Segher Boessenkool
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote: > > > On 17/07/2019 18:00, Segher Boessenkool wrote: > >On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote: > >>On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > >>>I'm not sure if it makes sense

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Richard Earnshaw (lists)
On 18/07/2019 16:30, Jakub Jelinek wrote: On Thu, Jul 18, 2019 at 04:26:26PM +0100, Richard Earnshaw (lists) wrote: On 18/07/2019 16:17, Jakub Jelinek wrote: On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote: Both directions: aarch64 c6x ia64 m68k nios2 parisc

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Jakub Jelinek
On Thu, Jul 18, 2019 at 04:26:26PM +0100, Richard Earnshaw (lists) wrote: > > > On 18/07/2019 16:17, Jakub Jelinek wrote: > > On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote: > > > > Both directions: > > > > aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa > > > > >

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Richard Earnshaw (lists)
On 18/07/2019 16:17, Jakub Jelinek wrote: On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote: Both directions: aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa AArch64 is Right only. Maybe hw-wise, but it has both rotr3 and rotl3 expanders. At least for GPRs.

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Jakub Jelinek
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote: > > Both directions: > >aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa > > AArch64 is Right only. Maybe hw-wise, but it has both rotr3 and rotl3 expanders. At least for GPRs. Jakub

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Richard Earnshaw (lists)
On 17/07/2019 18:00, Segher Boessenkool wrote: On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote: On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: I'm not sure if it makes sense to have both LROTATE_EXPR and RROTATE_EXPR on the GIMPLE level then (that CPUs only sup

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-18 Thread Jakub Jelinek
On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote: > I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED > for rotates? Not all immediates are valid of course, but that is a > separate issue. Well, we'd need to double check all the hw rotate instructions on al

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Kewen.Lin
on 2019/7/17 下午6:37, Richard Biener wrote: > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: >> >> Hi all, >> >> Based on the previous comments (thank you!), I tried to update the >> handling in expander and vectorizer. Middle-end optimizes lrotate >> with const rotation count to rrotate all th

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Segher Boessenkool
On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote: > On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > > I'm not sure if it makes sense to have both LROTATE_EXPR and > > RROTATE_EXPR on the GIMPLE level then (that CPUs only > > support one direction is natural though).

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Segher Boessenkool
On Wed, Jul 17, 2019 at 01:32:50PM +0200, Richard Biener wrote: > On Wed, Jul 17, 2019 at 12:54 PM Jakub Jelinek wrote: > Ick. I wouldn't even touch SHIFT_COUNT_TRUNCATED with a 10-foot pole > here. And for rotates we can simply always truncate constant amounts to > the rotated operands width, n

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Richard Biener
On Wed, Jul 17, 2019 at 1:32 PM Richard Biener wrote: > > On Wed, Jul 17, 2019 at 12:54 PM Jakub Jelinek wrote: > > > > On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > > > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: > > > > Based on the previous comments (thank you!), I t

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Richard Biener
On Wed, Jul 17, 2019 at 12:54 PM Jakub Jelinek wrote: > > On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: > > > Based on the previous comments (thank you!), I tried to update the > > > handling in expander and vectorizer. Midd

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Jakub Jelinek
On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote: > On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: > > Based on the previous comments (thank you!), I tried to update the > > handling in expander and vectorizer. Middle-end optimizes lrotate > > with const rotation count to rrotate

Re: [RFC] Consider lrotate const rotation in vectorizer

2019-07-17 Thread Richard Biener
On Tue, Jul 16, 2019 at 10:45 AM Kewen.Lin wrote: > > Hi all, > > Based on the previous comments (thank you!), I tried to update the > handling in expander and vectorizer. Middle-end optimizes lrotate > with const rotation count to rrotate all the time, it makes vectorizer > fail to vectorize if