https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #18 from Aleksey <rndfax at yandex dot ru> ---
(In reply to Andrew Pinski from comment #17)
> First off internal documentation is not user documentation.
> Second internal documentation is not always in sync with the code. In this
> case it seems like it is not fully.
I understand that docs not always in sync, so I don't trust the documentation,
I trust source code.
> Basically BB reordering does the full unfactoring these days.
I open gcc/bb-reorder.c and see this comment:
/* Duplicate the blocks containing computed gotos. This basically unfactors
computed gotos that were factored early on in the compilation process to
speed up edge based data flow. We used to not unfactor them again, which
can seriously pessimize code with many computed jumps in the source code,
such as interpreters. See e.g. PR15242. */
static void
duplicate_computed_gotos (function *fun)
It says "This basically unfactors computed gotos that were factored early". Is
it relevant comment?
According to algorithm in this function it does what it says in the comment.
I already provided:
1) this is compgoto step, it does not depend on option "-fno-reorder-blocks"
2) it seems it does not work in the edge cases
I already provided an example from RTL and stepped through the compgoto steps.
I pointed out that the last possible optimization does not take place: BB stays
with the last predecessor and compgoto finishes because of this. This last
predecessor must be merged too.
I'm just asking what the purpose of these conditions
if (single_pred_p (bb))
return false;
if (single_pred_p (bb))
continue;
in maybe_duplicate_computed_goto function?
What if these conditions must be removed?
