2016-12-17 21:25 GMT+01:00 Eric Anholt <e...@anholt.net>:
> Thomas Helland <thomashellan...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
