diff mbox

Fix two bugs in gimple-fold.c and/or folding (PR tree-optimization/46909)

Message ID 20101228210918.GR16156@tyan-ft48-01.lab.bos.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek Dec. 28, 2010, 9:09 p.m. UTC
On Tue, Dec 28, 2010 at 04:03:28PM -0500, Paul Koning wrote:
> 
> On Dec 28, 2010, at 3:41 PM, Richard Guenther wrote:
> 
> > On Tue, Dec 28, 2010 at 8:27 PM, Paul Koning <paul_koning@dell.com> wrote:
> >> I ran into an oddity with one of the testcases.
> >> 
> >> The one that scans the tree dump (gcc.dg/pr46909.c) fails for pdp11 because the tree dump file says it's checking for != 6 (which should be != 4).  But the generated code is correct.
> >> 
> >> Also curious is that the tree dump looks very different from the tree dump generated by the same rev compiler (give or take a few hours) on linux-x86.  Any idea what's going on here?
> > 
> > dependent on BRANCH_COST &&s and ||s will be lowered to control flow
> > or and/ors.  You don't provide source to make the point about the
> > !=6 vs !=4 issue.
> 
> The program being compiled is gcc/testsuite/gcc.dg/pr46909.c.  BRANCH_COST is constant 0 on the pdp11 target. 

If ifcombine optimizes the testcase into != 6 instead of != 4, then
you are looking at what was happening before the fix.

is the difference from the broken compiler to correct one.

	Jakub

Comments

Paul Koning Dec. 28, 2010, 9:38 p.m. UTC | #1
On Dec 28, 2010, at 4:09 PM, Jakub Jelinek wrote:

> On Tue, Dec 28, 2010 at 04:03:28PM -0500, Paul Koning wrote:
>> 
>> On Dec 28, 2010, at 3:41 PM, Richard Guenther wrote:
>> 
>>> On Tue, Dec 28, 2010 at 8:27 PM, Paul Koning <paul_koning@dell.com> wrote:
>>>> I ran into an oddity with one of the testcases.
>>>> 
>>>> The one that scans the tree dump (gcc.dg/pr46909.c) fails for pdp11 because the tree dump file says it's checking for != 6 (which should be != 4).  But the generated code is correct.
>>>> 
>>>> Also curious is that the tree dump looks very different from the tree dump generated by the same rev compiler (give or take a few hours) on linux-x86.  Any idea what's going on here?
>>> 
>>> dependent on BRANCH_COST &&s and ||s will be lowered to control flow
>>> or and/ors.  You don't provide source to make the point about the
>>> !=6 vs !=4 issue.
>> 
>> The program being compiled is gcc/testsuite/gcc.dg/pr46909.c.  BRANCH_COST is constant 0 on the pdp11 target. 
> 
> If ifcombine optimizes the testcase into != 6 instead of != 4, then
> you are looking at what was happening before the fix.

That's what I thought too.  But I'm definitely using the fixed compiler.  It's freshly built from a sandbox updated today, and in any case the generated code shows the correct check (a compare with 4, not a compare with 6).

I went back and did some more checking.  It turns out that, on pdp11, it makes no difference whether the fix is in or not; it generates correct code either way, and it produces the tree dump file that I mentioned (which looks drastically different from the linux-x86 treedump).

I just did another fresh configure/build to make sure I didn't have a mixed-up build -- no, it was clean.

	paul
diff mbox

Patch

--- pr46909.c.070t.ifcombine	2010-12-28 22:06:31.000000000 +0100
+++ pr46909.c.070t.ifcombine	2010-12-28 22:06:40.000000000 +0100
@@ -1,7 +1,7 @@ 
 
 ;; Function foo (foo)
 
-optimizing two comparisons to x_2(D) != 6
+optimizing two comparisons to x_2(D) != 4
 Merging blocks 2 and 3
 foo (unsigned int x)
 {
@@ -20,7 +20,7 @@  foo (unsigned int x)
   D.2691_6 = x_2(D) == 2;
   D.2692_7 = x_2(D) == 6;
   D.2693_8 = D.2691_6 | D.2692_7;
-  if (x_2(D) != 6)
+  if (x_2(D) != 4)
     goto <bb 4>;
   else
     goto <bb 3>;