[Bug rtl-optimization/17234] New: if-conversion bug on x86

[Bug rtl-optimization/17234] New: if-conversion bug on x86

[dann at godzilla dot ics dot uci dot edu]

Compiling 

void foo (unsigned *, unsigned *, unsigned);
unsigned *baz (unsigned) __attribute__ ((const));

struct COST
{
  unsigned *cost;

  unsigned maxWeakConstraintLevel;
};

unsigned * bar(struct COST *c)
{
  unsigned *valp;
  if(c->maxWeakConstraintLevel == 0)
    valp =0;
  else
    {
      valp = baz (4 * 33);
      foo (valp, c->cost, c->maxWeakConstraintLevel * sizeof(unsigned));
    }
  return valp;
}

with -O2 -fomit-frame-pointer on x86 generates:

bar:
        subl    $28, %esp
        movl    %edi, 24(%esp)
        movl    32(%esp), %edi
        movl    %esi, 20(%esp)
        xorl    %esi, %esi            <- [1] this should not be here
        movl    %ebx, 16(%esp)
        movl    4(%edi), %ebx
        testl   %ebx, %ebx
        jne     .L6                 
        movl    %esi, %eax             <- it should be before this instruction
        movl    16(%esp), %ebx
        movl    20(%esp), %esi
        movl    24(%esp), %edi
        addl    $28, %esp
        ret
        .p2align 4,,7
.L6:
        movl    $132, (%esp)
        call    baz
        movl    %eax, %esi         <- %esi is not used on this branch, 
                                    so [1] is partially dead code

The instruction [1] is put there by the if-conversion pass, when compiling
with -fno-ifconversion [1] appears only on one branch. 

gcc-3.3.3 does not have this problem, so this is a regression.

-- 
           Summary: if-conversion bug on x86
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dann at godzilla dot ics dot uci dot edu
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-30 11:33 -------
Confirmed. However, I can see the same problem with 3.2.3 and 3.3.4, so 
this doesn't seem to be a regression. Do I miss something, Dan? 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-30 11:33:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2004-08-30 15:25 -------
(In reply to comment #1)
> Confirmed. However, I can see the same problem with 3.2.3 and 3.3.4, so 
> this doesn't seem to be a regression. Do I miss something, Dan? 

I don't know, I only have access to one version of gcc on x86 at this moment,
here is what I get: 

bar:
        pushl   %esi
        pushl   %ebx
        pushl   %ebx
        movl    16(%esp), %ebx
        movl    4(%ebx), %ecx
        testl   %ecx, %ecx
        jne     .L2
        xorl    %esi, %esi   <- this is in the right place
.L3:
[snip]
        .ident  "GCC: (GNU) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)"



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2004-09-05 00:50 -------
This transformation is internally known as IF-CASE-1 and is performed during
the second if-conversion pass, .20.ce2.  From the CFG perspective this change
appears to be a win (at the point it is performed); by speculatively executing
a single instruction we reduce the CFG from four basic blocks to just three.

i.e.     0        0'
        / \       | \
       1   2  =>  |  2
        \ /       | /
         3        3

Normally, this simplification reduces the of unconditional branches in the
code, and allows for improved basic block reordering optimizations.
Unfortunately, in this case, basic block 3 marks the end of the function,
and we subsequently duplicate the function epilogue.  This later duplication
ends up turning both forms of the above CGF into 3 basic blocks, but the
if-conversion has pessimized the code with a partially dead assignment in
0' that could have remained in 3' (in the diagram below, reflecting the final CFG).

i.e.     0           0'
        / \    =>   / \
      1+3 2+3      3'  2+3

One solution may be to disable IF-CASE-1 is the join block is the last
basic block in the function, contains no additional instructions, and we're
expecting to duplicate the epilogue.

Jan, what do you think?  Is there an easy way to determine if the join block
of an IF-THEN-ELSE is a candidate for basic block duplication?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Last reconfirmed|2004-08-30 11:33:14         |2004-12-05 02:55:06
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-23 18:55 -------
Honza, Roger asked you something in comment #3, but you're not in the 
CC: list, so you probably missed it.  Care to comment? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-06-25 13:17 -------
Honza, ping ping ping !!!! 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234

[Bug rtl-optimization/17234] if-conversion bug on x86

[hubicka at gcc dot gnu dot org]

------- Comment #6 from hubicka at gcc dot gnu dot org  2006-04-30 14:24 -------
Sorry, I've must missed the two pings and noticed the problem only now while
housekeeping.
There is no easy way to peek cfglayout about what decisions it will do in
future, so there is no easy
way to decide whether to duplicate or not.  I am not sure if this is important
enought, but if we really care,
we might consider if-conversion to do the duplication itself for really small
blocks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234