Re: [RFC] Tree Loop Unroller Pass

2018-02-20 Thread Andrew Pinski
On Mon, Feb 12, 2018 at 3:55 PM, Kugan Vivekanandarajah wrote: > Implements tree loop unroller using the infrastructure provided. > > gcc/ChangeLog: > > 2018-02-12 Kugan Vivekanandarajah > > * Makefile.in (OBJS): Add

Re: [RFC] Tree loop unroller pass

2018-02-20 Thread Michael Matz
Hi, On Fri, 16 Feb 2018, Wilco Dijkstra wrote: > > How so? > > I thought it is well-known for many years that the rtl unroller doesn't > work properly. In practically all cases where LLVM beats GCC, it is due > to unrolling small loops. I thought it was because of vectorizing at -O2, not due

Re: [RFC] Tree loop unroller pass

2018-02-19 Thread Kugan Vivekanandarajah
Hi Richard, On 16 February 2018 at 22:56, Richard Biener wrote: > On Thu, Feb 15, 2018 at 11:30 PM, Kugan Vivekanandarajah > wrote: >> Hi Wilko, >> >> Thanks for your comments. >> >> On 14 February 2018 at 00:05, Wilco Dijkstra

Re: [RFC] Tree loop unroller pass

2018-02-16 Thread Wilco Dijkstra
Richard Biener wrote: > With Ooo CPUs speculatively executing the next iterations I very much doubt > that. OoO execution is like really dumb loop unrolling, you still have all the dependencies between iterations, all the branches, all the pointer increments etc. Optimizing those reduces

Re: [RFC] Tree loop unroller pass

2018-02-16 Thread Richard Biener
On February 16, 2018 3:22:22 PM GMT+01:00, Wilco Dijkstra wrote: >Richard Biener wrote: >>> This is a great plan - GCC urgently requires a good unroller! >> >> How so? > >I thought it is well-known for many years that the rtl unroller doesn't >work properly. >In

Re: [RFC] Tree loop unroller pass

2018-02-16 Thread Wilco Dijkstra
Richard Biener wrote: >> This is a great plan - GCC urgently requires a good unroller! > > How so? I thought it is well-known for many years that the rtl unroller doesn't work properly. In practically all cases where LLVM beats GCC, it is due to unrolling small loops. You may have noticed how

Re: [RFC] Tree loop unroller pass

2018-02-16 Thread Richard Biener
On Thu, Feb 15, 2018 at 11:30 PM, Kugan Vivekanandarajah wrote: > Hi Wilko, > > Thanks for your comments. > > On 14 February 2018 at 00:05, Wilco Dijkstra wrote: >> Hi Kugan, >> >>> Based on the previous discussions, I tried to implement

Re: [RFC] Tree loop unroller pass

2018-02-15 Thread Kugan Vivekanandarajah
Hi Wilko, Thanks for your comments. On 14 February 2018 at 00:05, Wilco Dijkstra wrote: > Hi Kugan, > >> Based on the previous discussions, I tried to implement a tree loop >> unroller for partial unrolling. I would like to queue this RFC patches >> for next stage1

Re: [RFC] Tree loop unroller pass

2018-02-13 Thread Wilco Dijkstra
Hi Kugan, > Based on the previous discussions, I tried to implement a tree loop > unroller for partial unrolling. I would like to queue this RFC patches > for next stage1 review. This is a great plan - GCC urgently requires a good unroller! > * Cost-model for selecting the loop uses the same

[RFC] Tree Loop Unroller Pass

2018-02-12 Thread Kugan Vivekanandarajah
Implements tree loop unroller using the infrastructure provided. gcc/ChangeLog: 2018-02-12 Kugan Vivekanandarajah * Makefile.in (OBJS): Add tree-ssa-loop-unroll.o. * common.opt (ftree-loop-unroll): New option. * passes.def: Add pass_tree_loop_uroll *

[RFC] Tree loop unroller pass

2018-02-12 Thread Kugan Vivekanandarajah
Hi All, Based on the previous discussions, I tried to implement a tree loop unroller for partial unrolling. I would like to queue this RFC patches for next stage1 review. In summary: * Cost-model for selecting the loop uses the same params used elsewhere in related optimizations. I was told