[Bug tree-optimization/68541] [6 Regression] Path splitting causes if-conversion miss

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-11-25
   Target Milestone|---                         |6.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I don't understand why we split the path here.  The condition is

  _9 = MEM[base: _13, offset: 0B];
  if (_9 >= 0)
    goto <bb 5>;
  else
    goto <bb 6>;
;;    succ:       5 [73.0%]  (TRUE_VALUE,EXECUTABLE)
;;                6 [27.0%]  (FALSE_VALUE,EXECUTABLE)

and thus has only a slight bias to true (73% vs. 27%).  Path splitting,
if I understood correctly, only makes sense if the most taken path can be
made an inner loop using more optimal BB placement.  Or if splitting the
path enables followup optimization in the duplicated tail - but then
this would fit more into DOM which actually does this kind of optimizations.

So - what for do we have this optimization again?

There is no check on kind of optimization / block frequency of any kind
in the pass, even optimize_*_for_size will happily duplicate all loop
tails if the CFG pattern matches.

Is this just for fun?  Or why doesn't this have any kind of cost-model?
I'd have expected that it at least honors sth like
--param max-jump-thread-duplication-stmts or so.

It also looks like it duplicates the block twice and throws away the
original (via making it unreachable).  Clearly wasteful.

Confirmed.