[Bug tree-optimization/70686] GIMPLE if-conversion slows down code

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Apr 18 07:47:00 GMT 2016


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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|-march=core2 /              |x86_64-*-*
                   |-march=nocona (alternating) |
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2016-04-18
          Component|c                           |tree-optimization
                 CC|                            |rguenth at gcc dot gnu.org
               Host|Intel Q8200 Quad Core /     |
                   |linux 4.5.0 x64             |
     Ever confirmed|0                           |1
            Summary|-fprofile-generate (not     |GIMPLE if-conversion slows
                   |fprofile-use) somehow       |down code
                   |produces much faster binary |

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's not so mind-blowing - it's simply that -fprofile-generate makes our
GIMPLE level if-conversion no longer apply.  Without -fprofile-generate
we if-convert the loop into

 for (i = 1; i <100000001; i++) 
 {
 ...

   b = b + (b < 1.00001) ? i + 12.43 : 0.0; 
...
}

thus we always evaluate the i + 12.43 and one additional addition of zero.

We do this to eventually enable vectorization but without any check
on whether it would be profitable when not vectorizing (your testcase
shows it's not profitable).

Confirmed.  -fno-tree-loop-if-convert should fix it in this particular case.


More information about the Gcc-bugs mailing list