On Fri, Mar 10, 2017 at 12:02 AM, Alexandre Oliva <aol...@redhat.com> wrote: > On Mar 8, 2017, Richard Biener <richard.guent...@gmail.com> wrote: > >> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva <aol...@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?
Just use the ID you use but instead of maintaining a hash-map and traverse that collect work items from the other hash-table into a vec and then sort after the ID. I was just thinking that if we're going all the way of having IDs then walking a hash-map of those IDs is not as good as we can do with similar cost? Richard. > > 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
