>From 5c9fa99d3f0cbb2a44d3e0507533f4ab5a13f906 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 11 Aug 2020 02:16:54 -0700 Subject: [PATCH 2/7] * src/fns.c (hash_table_rehash): Help the compiler a bit. --- src/fns.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/fns.c b/src/fns.c index 41e26104f3..9199178212 100644 --- a/src/fns.c +++ b/src/fns.c @@ -4250,14 +4250,16 @@ maybe_resize_hash_table (struct Lisp_Hash_Table *h) Normally there's never a need to recompute hashes. This is done only on first access to a hash-table loaded from the "pdump", because the objects' addresses may have changed, thus - affecting their hash. */ + affecting their hashes. */ void hash_table_rehash (Lisp_Object hash) { struct Lisp_Hash_Table *h = XHASH_TABLE (hash); + ptrdiff_t i, count = h->count; + /* Recompute the actual hash codes for each entry in the table. Order is still invalid. */ - for (ptrdiff_t i = 0; i < h->count; ++i) + for (i = 0; i < count; i++) { Lisp_Object key = HASH_KEY (h, i); Lisp_Object hash_code = h->test.hashfn (key, h); @@ -4268,7 +4270,8 @@ hash_table_rehash (Lisp_Object hash) eassert (HASH_NEXT (h, i) != i); /* Stop loops. */ } - for (ptrdiff_t i = h->count; i < ASIZE (h->next) - 1; i++) + ptrdiff_t size = ASIZE (h->next); + for (; i + 1 < size; i++) set_hash_next_slot (h, i, i + 1); } @@ -4892,7 +4895,6 @@ DEFUN ("hash-table-count", Fhash_table_count, Shash_table_count, 1, 1, 0, (Lisp_Object table) { struct Lisp_Hash_Table *h = check_hash_table (table); - return make_fixnum (h->count); } -- 2.17.1