[Mesa-dev] [PATCH] glsl: Remove useless walk of the hash table

Thomas Helland thomashelland90 at gmail.com
Sun Dec 18 00:37:00 UTC 2016


2016-12-17 21:25 GMT+01:00 Eric Anholt <eric at anholt.net>:
> Thomas Helland <thomashelland90 at gmail.com> writes:
>
>> We are removing the entry right beforehand, so this can never succeed.
>> Tested with a shader-db run. No changes in instruction count.
>> ---
>>  src/compiler/glsl/opt_copy_propagation.cpp | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/src/compiler/glsl/opt_copy_propagation.cpp b/src/compiler/glsl/opt_copy_propagation.cpp
>> index 247c498..faed0b2 100644
>> --- a/src/compiler/glsl/opt_copy_propagation.cpp
>> +++ b/src/compiler/glsl/opt_copy_propagation.cpp
>> @@ -306,20 +306,14 @@ ir_copy_propagation_visitor::kill(ir_variable *var)
>>
>>     /* Remove any entries currently in the ACP for this kill. */
>>     struct hash_entry *entry = _mesa_hash_table_search(acp, var);
>>     if (entry) {
>>        _mesa_hash_table_remove(acp, entry);
>>     }
>>
>> -   hash_table_foreach(acp, entry) {
>> -      if (var == (ir_variable *) entry->data) {
>> -         _mesa_hash_table_remove(acp, entry);
>> -      }
>> -   }
>> -
>
> The previous search is removing an entry with the key matching the var,
> while this loop is finding entries with the data mathcing the var.

Wow. Of course, you're correct. That's just embarrasing.
Apparently hacking at the middle of the night is a bad idea.


More information about the mesa-dev mailing list