This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stabilize store merging


On Mar  8, 2017, Richard Biener <richard.guenther@gmail.com> wrote:

> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> Don't let pointer randomization change the order in which we process
>> store chains.  This may cause SSA_NAMEs to be released in different
>> order, and if they're reused later, they may cause differences in SSA
>> partitioning, leading to differences in expand, and ultimately to
>> different code.

> Any reason you chose to maintain a new hash-map instead of at
> interesting places gather to-be-processed chains into a vector and
> sort that after IDs?

Where would we get such ids?  AFAICT base_addrs don't have to be decls,
they can be arbitrary expressions.

> Traversing the hash-map still doesn't get you
> a reliable order but only one depending on the chain creation and
> thus stmt walk order

True.  That's what all we need in general: output depends on stable
inputs only (relative order of stmts within BBs), not on random flukes
like pointer values within the compiler process.

> But it will for example still make testcase reduction fragile if
> shrinking the hash-map by removing unrelated code ends up processing
> things in different order.

True, if you remove or move the stmts that initiate a chain within a BB,
you will change the processing order.  There are many passes that will
process stmts or insns in the order they appear, so shuffling them will
yield different SSA version assignments, pseudo numbers and whatnot.
Why should this pass be held to a higher standard?

> So - if we fix this can we fix it by properly sorting things?

I don't see a way to do better, considering there's no real ID we could
use for sorting.  Do you?

Even if we were to use decl IDs rather than pointers in the tree
hashing, that would still make for impredictable ordering, because decl
ids are not necessarily stable across e.g. debug and nondebug
compilations.  Their order is, but if they were to appear within more
complex exprs, as we may have in this pass, hash computation would not
ensure decl id ordering is preserved.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]