* Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations [not found] <1316712613.83211.YahooMailNeo@web28503.mail.ukl.yahoo.com> @ 2011-09-22 19:59 ` charfi asma 2011-09-22 20:51 ` Ian Lance Taylor 2011-09-23 7:04 ` David Brown 0 siblings, 2 replies; 21+ messages in thread From: charfi asma @ 2011-09-22 19:59 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma @ 2011-09-22 20:51 ` Ian Lance Taylor 2011-09-23 7:04 ` David Brown 1 sibling, 0 replies; 21+ messages in thread From: Ian Lance Taylor @ 2011-09-22 20:51 UTC (permalink / raw) To: charfi asma; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma 2011-09-22 20:51 ` Ian Lance Taylor @ 2011-09-23 7:04 ` David Brown 2011-09-23 8:47 ` Georg-Johann Lay 1 sibling, 1 reply; 21+ messages in thread From: David Brown @ 2011-09-23 7:04 UTC (permalink / raw) To: gcc-help 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"). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 7:04 ` David Brown @ 2011-09-23 8:47 ` Georg-Johann Lay 2011-09-23 9:13 ` David Brown 0 siblings, 1 reply; 21+ messages in thread From: Georg-Johann Lay @ 2011-09-23 8:47 UTC (permalink / raw) To: David Brown; +Cc: gcc-help, charfiasma 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 8:47 ` Georg-Johann Lay @ 2011-09-23 9:13 ` David Brown 2011-09-23 15:16 ` David Brown 2011-09-23 15:53 ` Ian Lance Taylor 0 siblings, 2 replies; 21+ messages in thread From: David Brown @ 2011-09-23 9:13 UTC (permalink / raw) To: Georg-Johann Lay; +Cc: gcc-help, charfiasma 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 9:13 ` David Brown @ 2011-09-23 15:16 ` David Brown 2011-09-23 15:53 ` Ian Lance Taylor 1 sibling, 0 replies; 21+ messages in thread From: David Brown @ 2011-09-23 15:16 UTC (permalink / raw) To: gcc-help; +Cc: gcc-help, charfiasma 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 9:13 ` David Brown 2011-09-23 15:16 ` David Brown @ 2011-09-23 15:53 ` Ian Lance Taylor 2011-09-23 16:05 ` Jeff Kenton 2011-09-25 13:31 ` David Brown 1 sibling, 2 replies; 21+ messages in thread From: Ian Lance Taylor @ 2011-09-23 15:53 UTC (permalink / raw) To: David Brown; +Cc: Georg-Johann Lay, gcc-help, charfiasma 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 15:53 ` Ian Lance Taylor @ 2011-09-23 16:05 ` Jeff Kenton 2011-09-23 19:03 ` Jeff Law 2011-09-25 13:31 ` David Brown 1 sibling, 1 reply; 21+ messages in thread From: Jeff Kenton @ 2011-09-23 16:05 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: David Brown, Georg-Johann Lay, gcc-help, charfiasma 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 16:05 ` Jeff Kenton @ 2011-09-23 19:03 ` Jeff Law 2011-09-27 7:18 ` Miles Bader 0 siblings, 1 reply; 21+ messages in thread From: Jeff Law @ 2011-09-23 19:03 UTC (permalink / raw) To: Jeff Kenton Cc: Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma -----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----- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 19:03 ` Jeff Law @ 2011-09-27 7:18 ` Miles Bader 2011-09-27 9:35 ` Miles Bader 0 siblings, 1 reply; 21+ messages in thread From: Miles Bader @ 2011-09-27 7:18 UTC (permalink / raw) To: Jeff Law Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-27 7:18 ` Miles Bader @ 2011-09-27 9:35 ` Miles Bader 2011-09-27 11:29 ` Miles Bader 0 siblings, 1 reply; 21+ messages in thread From: Miles Bader @ 2011-09-27 9:35 UTC (permalink / raw) To: Jeff Law Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma 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))) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-27 9:35 ` Miles Bader @ 2011-09-27 11:29 ` Miles Bader 2011-09-27 16:47 ` Amker.Cheng 2011-09-28 0:03 ` Re : " charfi asma 0 siblings, 2 replies; 21+ messages in thread From: Miles Bader @ 2011-09-27 11:29 UTC (permalink / raw) To: Jeff Law Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-27 11:29 ` Miles Bader @ 2011-09-27 16:47 ` Amker.Cheng 2011-09-27 23:42 ` Jeff Law 2011-09-28 0:03 ` Re : " charfi asma 1 sibling, 1 reply; 21+ messages in thread From: Amker.Cheng @ 2011-09-27 16:47 UTC (permalink / raw) To: Miles Bader Cc: Jeff Law, Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-27 16:47 ` Amker.Cheng @ 2011-09-27 23:42 ` Jeff Law 0 siblings, 0 replies; 21+ messages in thread From: Jeff Law @ 2011-09-27 23:42 UTC (permalink / raw) To: Amker.Cheng Cc: Miles Bader, Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help, charfiasma -----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----- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-27 11:29 ` Miles Bader 2011-09-27 16:47 ` Amker.Cheng @ 2011-09-28 0:03 ` charfi asma 2011-09-28 8:59 ` Miles Bader 1 sibling, 1 reply; 21+ messages in thread From: charfi asma @ 2011-09-28 0:03 UTC (permalink / raw) To: Miles Bader, Jeff Law Cc: Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help ----- 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-28 0:03 ` Re : " charfi asma @ 2011-09-28 8:59 ` Miles Bader 0 siblings, 0 replies; 21+ messages in thread From: Miles Bader @ 2011-09-28 8:59 UTC (permalink / raw) To: charfi asma Cc: Jeff Law, Jeff Kenton, Ian Lance Taylor, David Brown, Georg-Johann Lay, gcc-help 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-23 15:53 ` Ian Lance Taylor 2011-09-23 16:05 ` Jeff Kenton @ 2011-09-25 13:31 ` David Brown 2011-09-25 13:50 ` David Brown 2011-09-26 10:57 ` Re : " charfi asma 1 sibling, 2 replies; 21+ messages in thread From: David Brown @ 2011-09-25 13:31 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Georg-Johann Lay, gcc-help, charfiasma 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-25 13:31 ` David Brown @ 2011-09-25 13:50 ` David Brown 2011-09-26 10:57 ` Re : " charfi asma 1 sibling, 0 replies; 21+ messages in thread From: David Brown @ 2011-09-25 13:50 UTC (permalink / raw) To: gcc-help; +Cc: Georg-Johann Lay, gcc-help, charfiasma 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-25 13:31 ` David Brown 2011-09-25 13:50 ` David Brown @ 2011-09-26 10:57 ` charfi asma 2011-09-26 15:35 ` Miles Bader 2011-09-26 22:47 ` Jeff Law 1 sibling, 2 replies; 21+ messages in thread From: charfi asma @ 2011-09-26 10:57 UTC (permalink / raw) To: David Brown; +Cc: Ian Lance Taylor, gcc-help, Jeff Law, avr 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-26 10:57 ` Re : " charfi asma @ 2011-09-26 15:35 ` Miles Bader 2011-09-26 22:47 ` Jeff Law 1 sibling, 0 replies; 21+ messages in thread From: Miles Bader @ 2011-09-26 15:35 UTC (permalink / raw) To: charfi asma; +Cc: David Brown, Ian Lance Taylor, gcc-help, Jeff Law, avr 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re : Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations 2011-09-26 10:57 ` Re : " charfi asma 2011-09-26 15:35 ` Miles Bader @ 2011-09-26 22:47 ` Jeff Law 1 sibling, 0 replies; 21+ messages in thread From: Jeff Law @ 2011-09-26 22:47 UTC (permalink / raw) To: charfi asma; +Cc: David Brown, Ian Lance Taylor, gcc-help, avr -----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----- ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-09-28 5:01 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1316712613.83211.YahooMailNeo@web28503.mail.ukl.yahoo.com> 2011-09-22 19:59 ` Tr : [redundency elimination, code motion, commun expression elimination] GCC optimizations charfi asma 2011-09-22 20:51 ` Ian Lance Taylor 2011-09-23 7:04 ` David Brown 2011-09-23 8:47 ` Georg-Johann Lay 2011-09-23 9:13 ` David Brown 2011-09-23 15:16 ` David Brown 2011-09-23 15:53 ` Ian Lance Taylor 2011-09-23 16:05 ` Jeff Kenton 2011-09-23 19:03 ` Jeff Law 2011-09-27 7:18 ` Miles Bader 2011-09-27 9:35 ` Miles Bader 2011-09-27 11:29 ` Miles Bader 2011-09-27 16:47 ` Amker.Cheng 2011-09-27 23:42 ` Jeff Law 2011-09-28 0:03 ` Re : " charfi asma 2011-09-28 8:59 ` Miles Bader 2011-09-25 13:31 ` David Brown 2011-09-25 13:50 ` David Brown 2011-09-26 10:57 ` Re : " charfi asma 2011-09-26 15:35 ` Miles Bader 2011-09-26 22:47 ` Jeff Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).