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 std::map for hash_map but I also think we s
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 require a linear walk of
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 hash-map and traverse
> that co
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 process
>>> store chains. This may cause SSA_NAMEs to be released in di
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
>> order, and if they're reused later, they may cause di
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
> partitioning, leading to di
