> On Tue, 4 Oct 2011, Andi Kleen wrote:
>
> > > Well, I'm not sure we should jump through too much hoops to make
> > > -flto work with -fno-toplevel-reorder. Simply because I think nothing
> > > defines any "toplevel order" for multiple object files. So, I think
> >
> > In practice it seems to
On Oct 4, 2011, at 6:03 AM, Andi Kleen wrote:
> Also as Honza pointed out it has other benefits, like making
> compiles more reproducible. For example if you have a memory corruption
> somewhere the random order currently will randomly move it from
> run to run and make it harder to debug.
I like
On Tue, 4 Oct 2011, Andi Kleen wrote:
> On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
>
> > Sure, the question is if "-flto" counts as magic and thus
> > "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> > (or 1to1) it would be reasonable to make -fno-tople
On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
> Sure, the question is if "-flto" counts as magic and thus
> "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> (or 1to1) it would be reasonable to make -fno-toplevel-reorder work
> (and thus maybe -fno-toplevel-
On Tue, 4 Oct 2011, Andi Kleen wrote:
> > Well, I'm not sure we should jump through too much hoops to make
> > -flto work with -fno-toplevel-reorder. Simply because I think nothing
> > defines any "toplevel order" for multiple object files. So, I think
>
> In practice it seems to work because r
> Well, I'm not sure we should jump through too much hoops to make
> -flto work with -fno-toplevel-reorder. Simply because I think nothing
> defines any "toplevel order" for multiple object files. So, I think
In practice it seems to work because real programs rely on it.
I can just say with thi
On Tue, 4 Oct 2011, Jan Hubicka wrote:
> > From: Andi Kleen
> >
> > Currently when reading in LTO sections from ld -r files they can
> > get randomly reordered based on hash tables and random IDs.
> > This causes reordering later when the final code is generated and
> > also makes crashes harder
> From: Andi Kleen
>
> Currently when reading in LTO sections from ld -r files they can
> get randomly reordered based on hash tables and random IDs.
> This causes reordering later when the final code is generated and
> also makes crashes harder to reproduce.
>
> This patch maintains explicit li
From: Andi Kleen
Currently when reading in LTO sections from ld -r files they can
get randomly reordered based on hash tables and random IDs.
This causes reordering later when the final code is generated and
also makes crashes harder to reproduce.
This patch maintains explicit lists based on the
