Re: Common Subexpression Elimination Opportunity not being exploited

2008-05-06 Thread Richard Guenther
On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote: Pranav Bhandarkar wrote: GCC 4.3 does fine here except when the operator is logical and (see attached. test.c uses logical and and test1.c uses plus) Logical and generates control-flow instructions, i.e. compares,

Re: Common Subexpression Elimination Opportunity not being exploited

2008-05-06 Thread Ramana Radhakrishnan
On Tue, May 6, 2008 at 8:11 AM, Richard Guenther [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote: Pranav Bhandarkar wrote: GCC 4.3 does fine here except when the operator is logical and (see attached. test.c uses logical and and test1.c

Re: Common Subexpression Elimination Opportunity not being exploited

2008-05-06 Thread Richard Guenther
On Tue, May 6, 2008 at 9:28 AM, Ramana Radhakrishnan [EMAIL PROTECTED] wrote: On Tue, May 6, 2008 at 8:11 AM, Richard Guenther [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 7:42 PM, Jim Wilson [EMAIL PROTECTED] wrote: Pranav Bhandarkar wrote: GCC 4.3 does fine here except

Re: Common Subexpression Elimination Opportunity not being exploited

2008-05-05 Thread Jim Wilson
Pranav Bhandarkar wrote: GCC 4.3 does fine here except when the operator is logical and (see attached. test.c uses logical and and test1.c uses plus) Logical and generates control-flow instructions, i.e. compares, branches, and labels. This makes optimizing it a very different problem than

Common Subexpression Elimination Opportunity not being exploited

2008-05-02 Thread Pranav Bhandarkar
Hi, I have a case where the code looks roughly like foo = i1 op i2; if (test1) bar1 = i1 op i2; if (test2) bar2 = i1 op i2; This can get converted into reg = i1 op i2 foo = reg if (test1) bar1 = reg if (test2) bar2 = reg GCC 4.3 does fine here except when the operator is logical and (see