delete_management.c:56:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < size; i++) {
^
delete_management.c:69:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = size - 100; i < size; i++) {
^
delete_management.c:79:31: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(key_value(entry->key) >= size - 100 &&
^
delete_management.c:79:70: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(key_value(entry->key) >= size - 100 &&
^
insert_many.c:56:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < size; i++) {
^
insert_many.c:62:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < size; i++) {
^
insert_many.c:67:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(ht->entries == size);
^
random_entry.c:62:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < size; i++) {
^
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We already have search_pre_hashed. This makes the APIs match better.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, the hash_table API required the user to do all of the hashing
of keys as it passed them in. Since the hashing function is intrinsically
tied to the comparison function, it makes sense for the hash table to know
about it. Also, it makes for a somewhat clumsy API as the user is
constantly calling hashing functions many of which have long names. This
is especially bad when the standard call looks something like
_mesa_hash_table_insert(ht, _mesa_pointer_hash(key), key, data);
In the above case, there is no reason why the hash table shouldn't do the
hashing for you. We leave the option for you to do your own hashing if
it's more efficient, but it's no longer needed. Also, if you do do your
own hashing, the hash table will assert that your hash matches what it
expects out of the hashing function. This should make it harder to mess up
your hashing.
v2: change to call the old entrypoint "pre_hashed" rather than
"with_hash", like cworth's equivalent change upstream (change by
anholt, acked-in-general by Jason).
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The tests in an empty stub, which we're currently building twice.
If anyone is interested in expanding it (adding actual tests) they
can always bring it back.
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This hash table is used in core Mesa, the GLSL compiler, and the i965
driver, which makes it a good candidate for the new src/util module.
It's much faster than program/hash_table.[ch] (see commit 6991c2922f
for data), and José's u_hash_table.c has a comment saying Gallium should
probably consider switching to a linear probing hash table at some point.
So this seems like the best candidate for a shared data structure.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Jason Ekstrand): Pick up another hash_table use and patch up scons
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For a long time, we've wanted a place to put utility code which isn't
directly tied to Mesa or Gallium internals. This patch creates a new
src/util directory for exactly that purpose, and builds the contents as
libmesautil.la.
ralloc seemed like a good first candidate. These days, it's directly
used by mesa/main, i965, i915, and r300g, so keeping it in src/glsl
didn't make much sense.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Jason Ekstrand): More realloc uses and some scons fixes
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
