[Bug middle-end/65224] fprofile-reorder-functions reorders using expand order

["hubicka at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yep, I am aware of this problem. Good we have tracking bug for this.

LRA is not the first pass down top-down propagation and I originally set up the
topological order precisely to make these kind of tricks possible (we propagate
stack alignments and also thinks like late pure-const, nothrow and similar
discoveries). 

There are several two downsides of this decision:

 1) The order also plays badly with unreachable code removal, because when all
uses of functions get optimized out late (that is quite frequent given that it
is first time we see code after IPA passes) we will not take the function away.
 2) The order is very bad for code layout, because it is backward (i.e. the
code basically executes from the end.  With IPA and rather large partitions
this matters.

I think we need both - the support for fragments and support for sections to
get output right.  The downside of sections is extra padding added between
functions that is undesirable unless we really want to get interprocedural
order right.

(I have a patch for non-FDO based reordering.  I would like to get that one in
next release, so it will become even more important to get this right).

I have prototype ipa-reorder pass solving 2) that produce sane function order
w/o need to have a profile. Of course it completely kills the top-down
propagation that is why I did not get around producing mainline version of it.

I also think we simply want to cut the late optimization queue once again:
execute all gimple optimization passes, re-do unreachable function removal and
only then proceed with expansion.