On Sat, Jan 13, 2018 at 2:48 PM, Jeff Law <l...@redhat.com> wrote: > On 01/12/2018 01:58 PM, li...@coryfields.com wrote: >> From: Cory Fields <cory-nosp...@coryfields.com> >> >> 2018-01-12 Cory Fields <cory-nosp...@coryfields.com> >> * tree-ira.c (allocno_hard_regs_compare): stabilize sort >> --- >> gcc/ChangeLog | 3 +++ >> gcc/ira-color.c | 3 +-- >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog >> index ab96bd6..546e84c 100644 >> --- a/gcc/ChangeLog >> +++ b/gcc/ChangeLog >> @@ -1,4 +1,7 @@ >> 2018-01-12 Cory Fields <cory-nosp...@coryfields.com> >> + * tree-ira.c (allocno_hard_regs_compare): stabilize sort > Note I'm not sure this is sufficient to stabilize the sort. Given two > allocnos with the same cost and the same potential hard reg set ought to > hash to the same value. >
If the set and cost are the same, then the two allocno_hard_regs are bit-for-bit identical, so returning 0 in that case is fine. Or have I misunderstood you? > Similarly if two sets with the same cost had a hash collision. A hash collision would cause breakage here, yes. I'd be happy to change it to a full memcmp-like compare, it just wasn't obvious to me how to do so. > > But it's still more stable than doing nothing. Agreed, it's enough to fix my bootstrap issues, at least. Side-note: I just noticed that I wrote the wrong filename in the changelog/commit msg. I assume those entries will likely change anyway if committed, but please let me know if I should re-send. Cory
