Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[charfi asma]

hello,

If GCC could optimize this code 


if (x=1)
{
a=b;
c=d;
e=f;
foo();

}
if (x=2)
{
a=b;
c=d;
e=f;
foo();
}  


to this one 


if (x=1) || (x=2)
{
a=b;
c=d;
e=f;
foo();
}

it will be implemented in which optimizations ? pre: partiel redundent elimination optimizaion or another one may be code motion ?

thank you very much

Asma

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Ian Lance Taylor]

charfi asma <charfiasma@yahoo.fr> writes:

> If GCC could optimize this code 
>
>
> if (x=1)
> {
> a=b;
> c=d;
> e=f;
> foo();
>
> }
> if (x=2)
> {
> a=b;
> c=d;
> e=f;
> foo();
> }  
>
>
> to this one 
>
>
> if (x=1) || (x=2)
> {
> a=b;
> c=d;
> e=f;
> foo();
> }
>
> it will be implemented in which optimizations ? pre: partiel redundent elimination optimizaion or another one may be code motion ?


I don't think gcc can do that optimization today.  There used be an
optimization -frtl-abstract-sequences which was vaguely similar, but it
didn't work well and was removed.  If this were to be implemented, it
would not be any of the existing optimizations; it would be something
different.

Ian

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown]

On 22/09/2011 21:59, charfi asma wrote:
> hello,
>
> If GCC could optimize this code
>
>
> if (x=1) { a=b; c=d; e=f; foo();  }
> if (x=2) { a=b; c=d; e=f; foo(); }
>
>
> to this one
>
> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>
> it will be implemented in which optimizations ? pre: partiel
> redundent elimination optimizaion or another one may be code motion?
>
> thank you very much
>
> Asma
>

gcc can't optimize code like this, because the two sequences have 
different effects.  In the first case, both sections are executed - 
first it sets "x" to 1, then does the {a=b;...foo();} code.  Then it 
sets "x" to 2 and does it again.  Depending on the locality and linkage 
of the variables, the compiler may be able to eliminate some of the 
assignments.  It will certainly be able to eliminate the conditional 
checks (unless "x" is volatile).  Your second sequence will only execute 
the code once (after the missing parenthesis are added).

If you had meant to write "if (x == 1)" instead of "if (x = 1)", then 
the question makes a little more sense.  But even then, it depends on 
whether foo() can access or change "x" (or more precisely, it depends on 
whether or not the compiler can be sure that foo() cannot read or change 
"x").

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Georg-Johann Lay]

David Brown schrieb:
> On 22/09/2011 21:59, charfi asma wrote:
>> hello,
>>
>> If GCC could optimize this code
>>
>>
>> if (x=1) { a=b; c=d; e=f; foo();  }
>> if (x=2) { a=b; c=d; e=f; foo(); }
>>
>>
>> to this one
>>
>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>
>> it will be implemented in which optimizations ? pre: partiel
>> redundent elimination optimizaion or another one may be code motion?
>>
>> thank you very much
>>
>> Asma
>>
> gcc can't optimize code like this, because the two sequences have
> different effects.  In the first case, both sections are executed -
> first it sets "x" to 1, then does the {a=b;...foo();} code.  Then it
> sets "x" to 2 and does it again.  Depending on the locality and linkage
> of the variables, the compiler may be able to eliminate some of the
> assignments.  It will certainly be able to eliminate the conditional
> checks (unless "x" is volatile).  Your second sequence will only execute
> the code once (after the missing parenthesis are added).
> 
> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
> the question makes a little more sense.  But even then, it depends on
> whether foo() can access or change "x" (or more precisely, it depends on
> whether or not the compiler can be sure that foo() cannot read or change
> "x").

It's the same for

  if (x == 1)      { a=b; c=d; e=f; foo(); }
  else if (x == 2) { a=b; c=d; e=f; foo(); }

GCC don't factor out the common part

Johann

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown]

On 23/09/2011 10:46, Georg-Johann Lay wrote:
> David Brown schrieb:
>> On 22/09/2011 21:59, charfi asma wrote:
>>> hello,
>>>
>>> If GCC could optimize this code
>>>
>>>
>>> if (x=1) { a=b; c=d; e=f; foo();  }
>>> if (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>>
>>> to this one
>>>
>>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>> it will be implemented in which optimizations ? pre: partiel
>>> redundent elimination optimizaion or another one may be code motion?
>>>
>>> thank you very much
>>>
>>> Asma
>>>
>> gcc can't optimize code like this, because the two sequences have
>> different effects.  In the first case, both sections are executed -
>> first it sets "x" to 1, then does the {a=b;...foo();} code.  Then it
>> sets "x" to 2 and does it again.  Depending on the locality and linkage
>> of the variables, the compiler may be able to eliminate some of the
>> assignments.  It will certainly be able to eliminate the conditional
>> checks (unless "x" is volatile).  Your second sequence will only execute
>> the code once (after the missing parenthesis are added).
>>
>> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
>> the question makes a little more sense.  But even then, it depends on
>> whether foo() can access or change "x" (or more precisely, it depends on
>> whether or not the compiler can be sure that foo() cannot read or change
>> "x").
>
> It's the same for
>
>    if (x == 1)      { a=b; c=d; e=f; foo(); }
>    else if (x == 2) { a=b; c=d; e=f; foo(); }
>
> GCC don't factor out the common part
>

You are right - which is odd, since there is no reason why it could not 
(unlike the original case where there is no "else").  Surely this would 
count as a significant missed optimisation, especially for big switch() 
code.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown]

On 23/09/2011 10:46, Georg-Johann Lay wrote:
> David Brown schrieb:
>> On 22/09/2011 21:59, charfi asma wrote:
>>> hello,
>>>
>>> If GCC could optimize this code
>>>
>>>
>>> if (x=1) { a=b; c=d; e=f; foo();  }
>>> if (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>>
>>> to this one
>>>
>>> if (x=1) || (x=2) { a=b; c=d; e=f; foo(); }
>>>
>>> it will be implemented in which optimizations ? pre: partiel
>>> redundent elimination optimizaion or another one may be code motion?
>>>
>>> thank you very much
>>>
>>> Asma
>>>
>> gcc can't optimize code like this, because the two sequences have
>> different effects.  In the first case, both sections are executed -
>> first it sets "x" to 1, then does the {a=b;...foo();} code.  Then it
>> sets "x" to 2 and does it again.  Depending on the locality and linkage
>> of the variables, the compiler may be able to eliminate some of the
>> assignments.  It will certainly be able to eliminate the conditional
>> checks (unless "x" is volatile).  Your second sequence will only execute
>> the code once (after the missing parenthesis are added).
>>
>> If you had meant to write "if (x == 1)" instead of "if (x = 1)", then
>> the question makes a little more sense.  But even then, it depends on
>> whether foo() can access or change "x" (or more precisely, it depends on
>> whether or not the compiler can be sure that foo() cannot read or change
>> "x").
>
> It's the same for
>
>    if (x == 1)      { a=b; c=d; e=f; foo(); }
>    else if (x == 2) { a=b; c=d; e=f; foo(); }
>
> GCC don't factor out the common part
>

You are right - which is odd, since there is no reason why it could not 
(unlike the original case where there is no "else").  Surely this would 
count as a significant missed optimisation, especially for big switch() 
code.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Ian Lance Taylor]

David Brown <david@westcontrol.com> writes:

>> It's the same for
>>
>>    if (x == 1)      { a=b; c=d; e=f; foo(); }
>>    else if (x == 2) { a=b; c=d; e=f; foo(); }
>>
>> GCC don't factor out the common part
>>
>
> You are right - which is odd, since there is no reason why it could
> not (unlike the original case where there is no "else").  Surely this
> would count as a significant missed optimisation, especially for big
> switch() code.

I don't think it is a significant missed optimization, as people rarely
write code like that.  They normally write

  if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }

The proposed optimization only applies when somebody has laboriously
written out the exact same sequence of code twice.

I'm not opposed to such an optimization if it works reliably and is not
too expensive.  I just don't think it will make much difference on
ordinary code.

Ian

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Jeff Kenton]

On 09/23/2011 11:16 AM, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com>  writes:
>
>>> It's the same for
>>>
>>>     if (x == 1)      { a=b; c=d; e=f; foo(); }
>>>     else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else").  Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
> I don't think it is a significant missed optimization, as people rarely
> write code like that.  They normally write
>
>    if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive.  I just don't think it will make much difference on
> ordinary code.
>
> Ian

People don't write that kind of code (we hope), but machine generated 
code can have all kinds of weirdness.  Still not a big deal, but it 
might be more common than you think.

--jeff

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/11 09:53, Jeff Kenton wrote:
> On 09/23/2011 11:16 AM, Ian Lance Taylor wrote:
>> David Brown<david@westcontrol.com>  writes:
>> 
>>>> It's the same for
>>>> 
>>>> if (x == 1)      { a=b; c=d; e=f; foo(); } else if (x == 2) {
>>>> a=b; c=d; e=f; foo(); }
>>>> 
>>>> GCC don't factor out the common part
>>>> 
>>> You are right - which is odd, since there is no reason why it
>>> could not (unlike the original case where there is no "else").
>>> Surely this would count as a significant missed optimisation,
>>> especially for big switch() code.
>> I don't think it is a significant missed optimization, as people
>> rarely write code like that.  They normally write
>> 
>> if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>> 
>> The proposed optimization only applies when somebody has
>> laboriously written out the exact same sequence of code twice.
>> 
>> I'm not opposed to such an optimization if it works reliably and
>> is not too expensive.  I just don't think it will make much
>> difference on ordinary code.
>> 
>> Ian
> 
> People don't write that kind of code (we hope), but machine
> generated code can have all kinds of weirdness.  Still not a big
> deal, but it might be more common than you think.
The tail merging code in the RTL optimizers might pick this stuff up
and Tom's work on block merging might as well.  It'd be worth looking
into why they aren't triggering.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOfK5HAAoJEBRtltQi2kC7pbIH/1tT4EPQlxJaUqlW4Strw6aE
1XfD5YHlcwnMvcbDbmZuglRVtQN+YZptw7rWfJ/47Pvad4yuzvOUmhQKUyYCd0q+
7bXXBDNP9irxoDOOuU5EA9678ZFIiCCDVFAy/ld3WmiP5UQ+Zkx4GEPwsWoIjmvh
umcCRFFQXK+Kosnxcqk9cbhYRg3/9aaP2FSuthoveZbRk9cZQcQyfyxz9RMaCli+
hFe6wh/l7d8h+8WUummebV9B5y+zKehtXH3G+f43EyWKm8LwnNPLLj6dU/1J/6IB
OPrPjgCLAbz+k7P28VpzSfW18td3wMnBFioE3t89PdJfQwTgYK1wC3iIdVkm8RA=
=we18
-----END PGP SIGNATURE-----

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Miles Bader]

Jeff Law <law@redhat.com> writes:
> The tail merging code in the RTL optimizers might pick this stuff up
> and Tom's work on block merging might as well.  It'd be worth
> looking into why they aren't triggering.

Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
two if-blocks:

   int a, b, c, d, e, f;
   extern void foo ();
   void t (int x)
   {
     if (x==1) { a=b; c=d; e=f; foo(); }
     if (x==2) { a=b; c=d; e=f; foo(); }
   }

=>

   t:
           cmpl	$1, %edi
           je	.L4
           cmpl	$2, %edi
           je	.L4
           rep
           ret
   .L4:
           movl	b(%rip), %eax
           movl	%eax, a(%rip)
           movl	d(%rip), %eax
           movl	%eax, c(%rip)
           movl	f(%rip), %eax
           movl	%eax, e(%rip)
           xorl	%eax, %eax
           jmp	foo
           ...
           .ident	"GCC: (Debian 20110924-1) 4.7.0 20110924 (experimental) [trunk revision 179143]"

-Miles

-- 
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
> two if-blocks:
...

and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!

So I dunno... what's the complaint again...?

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>> two if-blocks:
> ...
>
> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>
> So I dunno... what's the complaint again...?

I note that this optimization only takes place at -O2 or above; maybe
the original poster simply didn't use a high-enough optimization level?

-miles

-- 
I'd rather be consing.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Amker.Cheng]

On Tue, Sep 27, 2011 at 1:12 PM, Miles Bader <miles@gnu.org> wrote:
> Miles Bader <miles@gnu.org> writes:
>>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>>> two if-blocks:
>> ...
>>
>> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>>
>> So I dunno... what's the complaint again...?
>
> I note that this optimization only takes place at -O2 or above; maybe
> the original poster simply didn't use a high-enough optimization level?
>
> -miles
>
> --
> I'd rather be consing.
>

A case I ran into with gcc trunk after cprop1 pass:

  cc <- compare(r684, 0)
  if (cc != 0) goto .L1
  r191 <- 0
  goto .L2
.L1:
  r191 <- 0
  ...other insns
.L2:

In my experiment, both following pre and cse passes do not hoist the
r191<-0 to the beginning.
I understand that it is actually not a redundant case, and not pre's job.
So which pass in gcc might handle it? Thanks very much.

Wondering is it a similar story to the original post?
-- 
Best Regards.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/27/11 03:34, Amker.Cheng wrote:
> On Tue, Sep 27, 2011 at 1:12 PM, Miles Bader <miles@gnu.org>
> wrote:
>> Miles Bader <miles@gnu.org> writes:
>>>> Hmm, actually testing with a recent gcc snapshot, it _is_
>>>> merging the two if-blocks:
>>> ...
>>> 
>>> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same
>>> thing!
>>> 
>>> So I dunno... what's the complaint again...?
>> 
>> I note that this optimization only takes place at -O2 or above;
>> maybe the original poster simply didn't use a high-enough
>> optimization level?
>> 
>> -miles
>> 
>> -- I'd rather be consing.
>> 
> 
> A case I ran into with gcc trunk after cprop1 pass:
> 
> cc <- compare(r684, 0) if (cc != 0) goto .L1 r191 <- 0 goto .L2 
> .L1: r191 <- 0 ...other insns .L2:
> 
> In my experiment, both following pre and cse passes do not hoist
> the r191<-0 to the beginning. I understand that it is actually not
> a redundant case, and not pre's job. So which pass in gcc might
> handle it? Thanks very much.
> 
> Wondering is it a similar story to the original post?
What you've described is code hoisting.  pre and cse aren't going to
perform this optimization because on any given path through the CFG
only one r191<-0 statement will be executed.

Typically this isn't going to be caught by block or tail merging due
to "other insns".  However, there is a code hoisting pass that is
enabled by -Os which might catch this stuff.

jeff



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOgfwlAAoJEBRtltQi2kC7t4QH/0jeYAjLu9iafjsnY/CRElMk
ImkV8VNRJvbr4mYexI5JQoF63ZM3/LUwlfrU77UwLwEL/lbGt+i695UBmOX2UP2D
Xqvhb9fQFAT57oYMOAKr2ohPWs12LiJK1bPRv3HoARJfXamLX4OFYFJsD2srHO+y
dhNrEPQRfkn8jPWB2Ib7UtX48FZG0Oy4WWOqK8yPWk1RSW3eDSI8OEVXbSRaVMOC
K8oj2QAnPy8EulwSD8E0kEo4f2IqOCiMpDy5qMY5yrDA1AQwYdu71WH1y0fOCmZj
OnCCKK16fIxQQt3ifJAa9iE1H+U44O/DsIrbTS7Y5BMhQT4zFMaa8I8BVo0PGuc=
=LadS
-----END PGP SIGNATURE-----

Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[charfi asma]

----- Mail original -----
De : Miles Bader <miles@gnu.org>
À : Jeff Law <law@redhat.com>
Cc : Jeff Kenton <jkenton@tilera.com>; Ian Lance Taylor <iant@google.com>; David Brown <david@westcontrol.com>; Georg-Johann Lay <avr@gjlay.de>; gcc-help@gcc.gnu.org; charfiasma@yahoo.fr
Envoyé le : Mardi 27 Septembre 2011 7h12
Objet : Re: Tr : [redundency elimination, code motion, commun  expression elimination] GCC optimizations

Miles Bader <miles@gnu.org> writes:
>> Hmm, actually testing with a recent gcc snapshot, it _is_ merging the
>> two if-blocks:
> ...
>
> and in fact, gcc 4.4.6, 4.5.3, and 4.6.1 seem to do the same thing!
>
> So I dunno... what's the complaint again...?

I note that this optimization only takes place at -O2 or above; maybe
the original poster simply didn't use a high-enough optimization level?

-miles

-- 
I'd rather be consing.

Hello,

When I write the C code I tried to simplify the code cause actually I used nested switch cases and the code is not directly written in the main it is written in another function called in main.
this is the simplified code that GCC did not optimize when I compile the C++ code using -Os. (I used GCC: (GNU) 4.6.0 20110218 )
perhaps it deals with GCC intra optimizations ...

I am so sorry for the wrong simplification that I did (in the previous post) cause actually, GCC did factorize the common blocs as miles said but it did not factorize this example :(

int a,b,c,d;    

class MyClass
{
public : int x;
public : void foo()
{
d=10;
}
public : void foo1()
{

if (x==1)
{    
a=10;
b=11;
c=12;
foo();
}

if (x==2)
{    
a=10;
b=11;
c=12;
foo();
}

}
};
    
    
int main()
{
MyClass c;
c.x=1;
c.foo1();
c.foo1();
c.foo1();
return 0;
}

and this is the assembly code generated from it. 

    .weak    _ZN7MyClass4foo1Ev
    .type    _ZN7MyClass4foo1Ev, @function
_ZN7MyClass4foo1Ev:
.LFB1:
    cmpl    $1, (%rdi)
    jne    .L2
    movl    $10, a(%rip)
    movl    $11, b(%rip)
    movl    $12, c(%rip)
    movl    $10, d(%rip)
.L2:
    cmpl    $2, (%rdi)
    jne    .L1
    movl    $10, a(%rip)
    movl    $11, b(%rip)
    movl    $12, c(%rip)
    movl    $10, d(%rip)
.L1:
    ret
.LFE1:
    .size    _ZN7MyClass4foo1Ev, .-_ZN7MyClass4foo1Ev
    .section    .text.startup,"ax",@progbits
    .globl    main
    .type    main, @function
main:
.LFB2:
    subq    $24, %rsp
.LCFI0:
    leaq    12(%rsp), %rdi
    movl    $1, 12(%rsp)
    call    _ZN7MyClass4foo1Ev
    leaq    12(%rsp), %rdi
    call    _ZN7MyClass4foo1Ev
    leaq    12(%rsp), %rdi
    call    _ZN7MyClass4foo1Ev
    xorl    %eax, %eax
    addq    $24, %rsp
.LCFI1:
    ret
....
LEFDE3:
    .ident    "GCC: (GNU) 4.6.0 20110218 (experimental)"
    .section    .note.GNU-stack,"",@progbits

Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Miles Bader]

charfi asma <charfiasma@yahoo.fr> writes:
> this is the simplified code that GCC did not optimize when I compile
> the C++ code using -Os. (I used GCC: (GNU) 4.6.0 20110218 ) perhaps it
> deals with GCC intra optimizations ...

Using this example code, gcc 4.6.1 also doesn't merge the if-blocks for
me either (with -O2 or -Os).

gcc 4.7 (Debian 20110924-1) _does_ merge the if-blocks with -O2, but
_not_ with -Os.  [this seems slightly odd; isn't this kind of
tail-merging almost guaranteed to be a big win for -Os?]

-Mile

-- 
Defenceless, adj. Unable to attack.

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown]

On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com>  writes:
>
>>> It's the same for
>>>
>>>     if (x == 1)      { a=b; c=d; e=f; foo(); }
>>>     else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else").  Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that.  They normally write
>
>    if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive.  I just don't think it will make much difference on
> ordinary code.
>
> Ian
>

When you are talking about a simple case like this, then I agree.  The 
situation where I would expect to see it more is in switch statements 
where for various reasons you might have the same code for different 
cases, but have them separated for some reason.  Even more common is the 
situation when you have some commonality between the branches, but not 
completely identical cases.  The "tail merging" and "block merging" 
mentioned by Jeff Law sounds like optimisations to suit such cases.

It is always possible that these optimisations /are/ triggered by such 
code for current and development versions of gcc - the compiler I tested 
with was gcc 4.5.1 (since that's the version I have conveniently 
available at the moment).

David

Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[David Brown]

On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com>  writes:
>
>>> It's the same for
>>>
>>>     if (x == 1)      { a=b; c=d; e=f; foo(); }
>>>     else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else").  Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that.  They normally write
>
>    if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive.  I just don't think it will make much difference on
> ordinary code.
>
> Ian
>

When you are talking about a simple case like this, then I agree.  The 
situation where I would expect to see it more is in switch statements 
where for various reasons you might have the same code for different 
cases, but have them separated for some reason.  Even more common is the 
situation when you have some commonality between the branches, but not 
completely identical cases.  The "tail merging" and "block merging" 
mentioned by Jeff Law sounds like optimisations to suit such cases.

It is always possible that these optimisations /are/ triggered by such 
code for current and development versions of gcc - the compiler I tested 
with was gcc 4.5.1 (since that's the version I have conveniently 
available at the moment).

David

Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[charfi asma]

Hello every body,

First of all, thank you for all your responses ;) 


this situation is frequent in real time and embedded system development (developper use switch cas statements to express the behavior of the system).

I think that GCC purpose is to help developper to produce an optimized code for their application. developper are not obliged to optimize the code, we have to be happy if they manage to write the correct code (that runs just like developper want it to run). Otherwise, optimization is the GCC stuff...
@ David: if (x=1) was a typo, I meant if (x==1).

you said that The "tail merging" and "block merging" 
mentioned by Jeff Law sounds like optimisations to suit such cases.

I tested with gcc 4.6 (the current gcc version) I compiled the code using -Os and GCC did not optimize the code. did block merging and tail merging are not included in -Os ?

thank you very much

Asma





----- Mail original -----
De : David Brown <david@westcontrol.com>
À : Ian Lance Taylor <iant@google.com>
Cc : Georg-Johann Lay <avr@gjlay.de>; gcc-help@gcc.gnu.org; charfiasma@yahoo.fr
Envoyé le : Samedi 24 Septembre 2011 17h07
Objet : Re: Tr : [redundency elimination, code motion, commun  expression elimination] GCC optimizations

On 23/09/2011 17:16, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com>  writes:
>
>>> It's the same for
>>>
>>>     if (x == 1)      { a=b; c=d; e=f; foo(); }
>>>     else if (x == 2) { a=b; c=d; e=f; foo(); }
>>>
>>> GCC don't factor out the common part
>>>
>>
>> You are right - which is odd, since there is no reason why it could
>> not (unlike the original case where there is no "else").  Surely this
>> would count as a significant missed optimisation, especially for big
>> switch() code.
>
> I don't think it is a significant missed optimization, as people rarely
> write code like that.  They normally write
>
>    if (x == 1 || x == 2) { a=b; c=d; e=f; foo(); }
>
> The proposed optimization only applies when somebody has laboriously
> written out the exact same sequence of code twice.
>
> I'm not opposed to such an optimization if it works reliably and is not
> too expensive.  I just don't think it will make much difference on
> ordinary code.
>
> Ian
>

When you are talking about a simple case like this, then I agree.  The 
situation where I would expect to see it more is in switch statements 
where for various reasons you might have the same code for different 
cases, but have them separated for some reason.  Even more common is the 
situation when you have some commonality between the branches, but not 
completely identical cases.  The "tail merging" and "block merging" 
mentioned by Jeff Law sounds like optimisations to suit such cases.

It is always possible that these optimisations /are/ triggered by such 
code for current and development versions of gcc - the compiler I tested 
with was gcc 4.5.1 (since that's the version I have conveniently 
available at the moment).

David

Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Miles Bader]

charfi asma <charfiasma@yahoo.fr> writes:
> I tested with gcc 4.6 (the current gcc version) I compiled the code
> using -Os and GCC did not optimize the code. did block merging and tail
> merging are not included in -Os ?

You should really check with a recent version of the development trunk.

[If you're using debian, this is available in the "gcc-snapshot"
package -- very handy!]

-Miles

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/11 03:06, charfi asma wrote:
> Hello every body,
> 
> First of all, thank you for all your responses ;)
> 
> 
> this situation is frequent in real time and embedded system
> development (developper use switch cas statements to express the
> behavior of the system).
> 
> I think that GCC purpose is to help developper to produce an
> optimized code for their application. developper are not obliged to
> optimize the code, we have to be happy if they manage to write the
> correct code (that runs just like developper want it to run).
> Otherwise, optimization is the GCC stuff... @ David: if (x=1) was a
> typo, I meant if (x==1).
> 
> you said that The "tail merging" and "block merging" mentioned by
> Jeff Law sounds like optimisations to suit such cases.
> 
> I tested with gcc 4.6 (the current gcc version) I compiled the code
> using -Os and GCC did not optimize the code. did block merging and
> tail merging are not included in -Os ?
> 
Tom's changes aren't in GCC 4.6, you'd have to test the current sources.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOgK3kAAoJEBRtltQi2kC7IpkH/1aZzqaHYWOgBotOntRoMsHM
SS1qmsr2AdK33tiEDCvMVRA3sfAN8s8wfhpudYK0dTL5/VG2KhNipdSHZp3N7CgX
7EYuOebVU0na1ucvBChHdCDiIXV5u81UjPr8t7fwK7x78k5/2xeuMAv2U2DvPWmk
8hH9IDzFppSWFE413gnT5ONEoYImINWaAiiAINU/OsxblTpTh4UGl7wfdygzIcGc
k3txE2fRGel07hJvy0T72MtkPuCfw2ISa262/yN4zpEIwh8nssljy4pb4Wos55Dl
IAEHNgxlAxfJoDVjpZVmqf80a8nNRa9OV1pUlN5+gYM/QABmT25QIVE2KWse3j4=
=L+dW
-----END PGP SIGNATURE-----