[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-28
               Host|i686-pc-linux-gnu           |
     Ever Confirmed|0                           |1
              Build|i686-pc-linux-gnu           |

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-28 02:11:24 UTC ---
        jg      .L2             # Shouldn't these two just
        jge     .L6             # be one "je .L6"?

Is fixed with:
2007-06-12  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/15353
        PR tree-optimization/31657
        * passes.c (init_optimization_passes): Add pass_tree_ifcombine.
        * timevar.def: Add TV_TREE_IFCOMBINE.

The other parts are confirmed.

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
>         jg      .L2             # Shouldn't these two just
>         jge     .L6             # be one "je .L6"?
> 
> Is fixed with:
> 2007-06-12  Richard Guenther  <rguenther@suse.de>
> 
>         PR tree-optimization/15353
>         PR tree-optimization/31657
>         * passes.c (init_optimization_passes): Add pass_tree_ifcombine.
>         * timevar.def: Add TV_TREE_IFCOMBINE.
> 
> The other parts are confirmed.

Except it is no longer fixed by that.  That broke in GCC 10.

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Except it is no longer fixed by that.  That broke in GCC 10.

It broke in GCC 10 because we now have:
```
  if (_10 < _12)
    goto <bb 3>; [1.04%]
  else
    goto <bb 4>; [98.96%]

  <bb 3> [local count: 11166912]:
  d1 ={v} {CLOBBER(eol)};
  d2 ={v} {CLOBBER(eol)};
  goto <bb 8>; [100.00%]

  <bb 4> [local count: 1062574912]:
  if (_10 > _12)
    goto <bb 5>; [34.00%]
  else
    goto <bb 6>; [66.00%]

  <bb 5> [local count: 361275474]:
  d1 ={v} {CLOBBER(eol)};
  d2 ={v} {CLOBBER(eol)};
  goto <bb 8>; [100.00%]
```
Which can be figured out is the same via `code hoisting` pass.

[Bug rtl-optimization/31889] New: compiler misses opportunity to combine multiple identical function return paths

[raeburn at raeburn dot org]

The source file I'm submitting has two implementations of an inline function,
and a second function which calls it and then prints one of two strings
depending on the return value.  With the simpler implementation of the inline
function, one call to puts() is followed by a jump to the return sequence
emitted after the other puts() call.  With the more complicated (but
functionally equivalent) implementation of the inline function, the caller's
two paths aren't combined; two sets of instructions are emitted to restore the
same registers from the same stack slots before returning.  It should still be
able to combine them.

(A second possible missed optimization?  The branch could've been done to the
puts call, instead of to just after, saving one call instruction.  Unless a
branch to a call is slower than a call that returns to a branch instruction on
these processors.)


-- 
           Summary: compiler misses opportunity to combine multiple
                    identical function return paths
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: raeburn at raeburn dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[raeburn at raeburn dot org]

------- Comment #1 from raeburn at raeburn dot org  2007-05-10 06:04 -------
Created an attachment (id=13539)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13539&action=view)
sample source code, with assembly & comments


-- 


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

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[steven at gcc dot gnu dot org]

------- Comment #2 from steven at gcc dot gnu dot org  2007-05-10 07:13 -------
Try compiling with "--param min-crossjump-insns=1".  I'm curious to hear if
that fixes this problem for you.


-- 


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

[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths

[raeburn at raeburn dot org]

------- Comment #3 from raeburn at raeburn dot org  2007-05-10 22:25 -------
Subject: Re:  compiler misses opportunity to combine multiple identical
function return paths

On May 10, 2007, at 2:13, steven at gcc dot gnu dot org wrote:
> ------- Comment #2 from steven at gcc dot gnu dot org  2007-05-10  
> 07:13 -------
> Try compiling with "--param min-crossjump-insns=1".  I'm curious to  
> hear if
> that fixes this problem for you.

Yes, with that option, the second path loads the pointer to the  
string to be displayed, and jumps to the puts call.  Actually, it  
does for both versions of the code, the hairier form and the simpler  
form, which were producing different (but functionally equivalent)  
less-optimal code before.

Ken


-- 


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