Re: stabilize store merging

On Fri, Mar 10, 2017 at 11:34 PM, Alexandre Oliva wrote: > On Mar 10, 2017, Alexandre Oliva wrote: > >> Now, if there's something you dislike about maps, we could make it a >> doubly-linked list, or maybe even a singly-linked list. I indeed mis-matched

Re: stabilize store merging

On Mar 10, 2017, Alexandre Oliva wrote: > Now, if there's something you dislike about maps, we could make it a > doubly-linked list, or maybe even a singly-linked list. Scratch that, there's a use that may remove after a lookup by base_addr, so a singly-linked list would

Re: stabilize store merging

On Mar 10, 2017, Richard Biener wrote: >>> 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

Re: stabilize store merging

On Fri, Mar 10, 2017 at 12:02 AM, Alexandre Oliva wrote: > On Mar 8, 2017, Richard Biener wrote: > >> On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva wrote: >>> Don't let pointer randomization change the order in which we

Re: stabilize store merging

On Mar 8, 2017, Richard Biener wrote: > On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva 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 >>

Re: stabilize store merging

On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva 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 >

stabilize store merging

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.