Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Wed, May 4, 2016 at 6:57 PM, kugan wrote: > Hi Richard, > >> >> maybe instert_stmt_after will help here, I don't think you got the >> insertion >> logic correct, thus insert_stmt_after (mul_stmt, def_stmt) which I think >> misses GIMPLE_NOP handling. At least >> >> + if (SSA_NAME_VAR (op)

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Thu, May 5, 2016 at 3:57 AM, kugan wrote: > Hi Richard, > >> >> maybe instert_stmt_after will help here, I don't think you got the >> insertion >> logic correct, thus insert_stmt_after (mul_stmt, def_stmt) which I think >> misses GIMPLE_NOP handling. At least >> >> + if (SSA_NAME_VAR (op)

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

Hi Richard, maybe instert_stmt_after will help here, I don't think you got the insertion logic correct, thus insert_stmt_after (mul_stmt, def_stmt) which I think misses GIMPLE_NOP handling. At least + if (SSA_NAME_VAR (op) != NULL huh? I suppose you could have tested SSA_NAME_IS_DEFAUL

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Sun, Apr 24, 2016 at 12:02 AM, kugan wrote: > Hi Richard, > > As you have said in the other email, I tried implementing with the > add_reapeats_to_ops_vec but the whole repeat vector is designed for > MULT_EXPR chain. I tried changing it but it turned out to be not > straightforward without lot

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

Hi Richard, As you have said in the other email, I tried implementing with the add_reapeats_to_ops_vec but the whole repeat vector is designed for MULT_EXPR chain. I tried changing it but it turned out to be not straightforward without lots of re-write. Therefore I tried to implement based on

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Tue, Apr 19, 2016 at 1:56 PM, Richard Biener wrote: > On Wed, Mar 2, 2016 at 3:28 PM, Christophe Lyon > wrote: >> On 29 February 2016 at 05:28, kugan >> wrote: >>> That looks better, but I think the unordered_remove will break operand sorting and thus you probably don't handle

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Wed, Mar 2, 2016 at 3:28 PM, Christophe Lyon wrote: > On 29 February 2016 at 05:28, kugan wrote: >> >>> That looks better, but I think the unordered_remove will break operand >>> sorting >>> and thus you probably don't handle x + x + x + x + y + y + y + y + y + >>> y + z + z + z + z >>> optima

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On 29 February 2016 at 05:28, kugan wrote: > >> That looks better, but I think the unordered_remove will break operand >> sorting >> and thus you probably don't handle x + x + x + x + y + y + y + y + y + >> y + z + z + z + z >> optimally. >> >> I'd say you simply want to avoid the recursion and co

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

That looks better, but I think the unordered_remove will break operand sorting and thus you probably don't handle x + x + x + x + y + y + y + y + y + y + z + z + z + z optimally. I'd say you simply want to avoid the recursion and collect a vector of [start, end] pairs before doing any modificat

Re: [RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

On Fri, Feb 26, 2016 at 4:02 AM, kugan wrote: > > > Hi, > > This is an attempt to fix missed optimization: x+x+x+x -> 4*x as reported in > PR63586. > > Regression tested and bootstrapped on x86-64-linux-gnu with no new > regressions. > > Is this OK for next stage1? That looks better, but I think

[RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

Hi, This is an attempt to fix missed optimization: x+x+x+x -> 4*x as reported in PR63586. Regression tested and bootstrapped on x86-64-linux-gnu with no new regressions. Is this OK for next stage1? Thanks, Kugan gcc/testsuite/ChangeLog: 2016-02-26 Kugan Vivekanandarajah PR