[Bug rtl-optimization/71785] Computed gotos are mostly optimized away

[rndfax at yandex dot ru]

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

--- Comment #14 from Aleksey <rndfax at yandex dot ru> ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Aleksey from comment #12)
> > But adding these two flags "-fno-reorder-blocks-and-partition
> > -fno-reorder-blocks"
> 
> If you say that basic blocks should not be reordered, then they
> are not.  All behaving perfectly as expected.
> 
> These options will cause exactly the same kind of "problems"
> everywhere else as well.
> 
> > Is it possible to fix that?
> 
> Yes, don't use compilers options that degrade performance, if
> you want good performance?

Performance is not the case here, so don't bother with it. Strict order of
labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this is
what is important.

Documentation (https://gcc.gnu.org/onlinedocs/gccint/Edges.html#Edges) says
"During the earlier stages of the compilation process, GCC tries to avoid such
dense flow graphs by factoring computed jumps". Then it states that "the
computed jumps are un-factored in the later passes of the compiler (in the pass
called pass_duplicate_computed_gotos)".

It would be helpful if you give the explanation how these options affect
"un-factoring".