Re: [PATCH] Improve combining of conditionals

2011-04-25 Thread Maxim Kuvyrkov
On Apr 15, 2011, at 4:38 PM, Maxim Kuvyrkov wrote: > On Apr 15, 2011, at 3:34 PM, Eric Botcazou wrote: > >>> The problem this patch fixes is that combine_simplify_rtx() prefers to >>> return an expression (say, ) even when a comparison is >>> prefered (say, ). Expressions are not recognized as >

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Mike Stump
On Apr 15, 2011, at 10:22 AM, Eric Botcazou wrote: >> If it can be bool, it should be bool. > > Rather basic principle IMO. Consistency is of much greater value. Yes, and consistency is had by upgrading existing int uses that should be bool to bool as they are spotted :-) I prefer doing t

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Eric Botcazou
> If it can be bool, it should be bool. Rather basic principle IMO. Consistency is of much greater value. -- Eric Botcazou

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Mike Stump
On Apr 15, 2011, at 3:44 AM, Eric Botcazou wrote: >> And make IN_COND a bool instead of an int? > > I had the same initial reaction but then came to the same conclusion as Maxim. If it can be bool, it should be bool.

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Maxim Kuvyrkov
On Apr 15, 2011, at 3:34 PM, Eric Botcazou wrote: >> The problem this patch fixes is that combine_simplify_rtx() prefers to >> return an expression (say, ) even when a comparison is >> prefered (say, ). Expressions are not recognized as >> valid conditions of if_then_else for most targets, so com

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Eric Botcazou
> The problem this patch fixes is that combine_simplify_rtx() prefers to > return an expression (say, ) even when a comparison is > prefered (say, ). Expressions are not recognized as > valid conditions of if_then_else for most targets, so combiner misses a > potential optimization. This patch ma

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Eric Botcazou
> And make IN_COND a bool instead of an int? I had the same initial reaction but then came to the same conclusion as Maxim. -- Eric Botcazou

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Maxim Kuvyrkov
On Apr 15, 2011, at 2:38 PM, Steven Bosscher wrote: > On Fri, Apr 15, 2011 at 11:04 AM, Eric Botcazou wrote: >> @@ -4938,11 +4938,13 @@ find_split_point (rtx *loc, rtx insn, bool set_src) >> >>IN_DEST is nonzero if we are processing the SET_DEST of a SET. >> >> + IN_COND is nonzero if we

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Steven Bosscher
On Fri, Apr 15, 2011 at 11:04 AM, Eric Botcazou wrote: > @@ -4938,11 +4938,13 @@ find_split_point (rtx *loc, rtx insn, bool set_src) > >    IN_DEST is nonzero if we are processing the SET_DEST of a SET. > > +   IN_COND is nonzero if we are on top level of the condition. > > "...we are at the top l

Re: [PATCH] Improve combining of conditionals

2011-04-15 Thread Eric Botcazou
> The patch was successfully tested on {i686, arm, mips}-linux, both GCC > testsuites and SPEC2000 runs. For all targets there was no observable code > difference in SPEC2000 benchmarks, so the example does not trigger very > often. Still, it speeds up CoreMark by about 1%. > > OK for trunk? Yes

[PATCH] Improve combining of conditionals

2011-04-15 Thread Maxim Kuvyrkov
This patch fixes the problem with substituting expressions into IF_THEN_ELSE during combining. Without this patch combining of conditionals inside IF_THEN_ELSE is seriously inhibited. The problem this patch fixes is that combine_simplify_rtx() prefers to return an expression (say, ) even when