Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-28 Thread Richard Biener via Gcc-patches
On Fri, Sep 25, 2020 at 4:15 PM Martin Liška wrote: > > On 9/25/20 3:45 PM, Richard Biener wrote: > > On Fri, Sep 25, 2020 at 3:32 PM Martin Liška wrote: > >> > >> On 9/25/20 3:18 PM, Richard Biener wrote: > >>> On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote: > > Hello. > > >

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Martin Liška
On 9/25/20 3:45 PM, Richard Biener wrote: On Fri, Sep 25, 2020 at 3:32 PM Martin Liška wrote: On 9/25/20 3:18 PM, Richard Biener wrote: On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote: Hello. All right, I come up with a rapid speed up that can allow us to remove the introduced paramet

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Martin Liška
On 9/25/20 3:52 PM, Jakub Jelinek wrote: On Fri, Sep 25, 2020 at 11:13:06AM +0200, Martin Liška wrote: --- a/gcc/tree-switch-conversion.c +++ b/gcc/tree-switch-conversion.c @@ -1268,6 +1268,15 @@ jump_table_cluster::can_be_handled (const vec &clusters, if (range == 0) return false;

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Jakub Jelinek via Gcc-patches
On Fri, Sep 25, 2020 at 11:13:06AM +0200, Martin Liška wrote: > --- a/gcc/tree-switch-conversion.c > +++ b/gcc/tree-switch-conversion.c > @@ -1268,6 +1268,15 @@ jump_table_cluster::can_be_handled (const vec *> &clusters, >if (range == 0) > return false; > > + unsigned HOST_WIDE_INT lhs

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Richard Biener via Gcc-patches
On Fri, Sep 25, 2020 at 3:32 PM Martin Liška wrote: > > On 9/25/20 3:18 PM, Richard Biener wrote: > > On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote: > >> > >> Hello. > >> > >> All right, I come up with a rapid speed up that can allow us to remove > >> the introduced parameter. It contains 2

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Martin Liška
On 9/25/20 3:18 PM, Richard Biener wrote: On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote: Hello. All right, I come up with a rapid speed up that can allow us to remove the introduced parameter. It contains 2 parts: - BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Richard Biener via Gcc-patches
On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote: > > Hello. > > All right, I come up with a rapid speed up that can allow us to remove > the introduced parameter. It contains 2 parts: > - BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE > - JT: we spent quite some time in

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-25 Thread Martin Liška
Hello. All right, I come up with a rapid speed up that can allow us to remove the introduced parameter. It contains 2 parts: - BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE - JT: we spent quite some time in density calculation, we can guess it first and it leads to a fa

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-23 Thread Jakub Jelinek via Gcc-patches
On Tue, Sep 22, 2020 at 02:19:12PM +0200, Richard Biener via Gcc-patches wrote: > On September 22, 2020 1:22:12 PM GMT+02:00, "Martin Liška" > wrote: > >Hi. > > > >The patch is about a bail out limit that needs to be added to switch > >lowering. > >Currently the algorithm is quadratic and needs s

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-22 Thread Martin Liška
On 9/22/20 2:19 PM, Richard Biener wrote: OK. Though the default limit looks high? Yep, I'm going to install it with the param default value equal to 1. Thanks, Martin

Re: [PATCH] switch lowering: limit number of cluster attemps

2020-09-22 Thread Richard Biener via Gcc-patches
On September 22, 2020 1:22:12 PM GMT+02:00, "Martin Liška" wrote: >Hi. > >The patch is about a bail out limit that needs to be added to switch >lowering. >Currently the algorithm is quadratic and needs some bail out. I've >tested value >of 100K which corresponds to about 0.2s in the problematic t