Displaying 4 results from an estimated 4 matches for "slow_filter_table".
2008 Mar 29
2
[LLVMdev] Introducing a branch optimization and prediction pass
...might not be always be safe to move
out of the branch's body (because the condition could be required to
ensure the access is valid),
or it could actually decrease performance in case the guarding condition
is to prevent L2 cache misses, example:
if(fast_filter_table[value] == match && slow_filter_table[value] ==
match) { ... do something ... }
If we unconditionally read from slow_filter_table it could actually
reduce the performance (assume slow_filter_table is huge), and might not
be legal because we violate
the short-circuit evaluation.
(BTW, the branch predictor should say it is predictable,...
2008 Mar 31
0
[LLVMdev] Introducing a branch optimization and prediction pass
...move
> out of the branch's body (because the condition could be required to
> ensure the access is valid),
> or it could actually decrease performance in case the guarding
> condition
> is to prevent L2 cache misses, example:
> if(fast_filter_table[value] == match && slow_filter_table[value] ==
> match) { ... do something ... }
That's something to worry about later. :-)
>
>
> If we unconditionally read from slow_filter_table it could actually
> reduce the performance (assume slow_filter_table is huge), and might
> not
> be legal because we violate
&g...
2008 Mar 31
2
[LLVMdev] Introducing a branch optimization and prediction pass
...ee to always transform Select into CMOV/SETCC (or
>> equivalent), on targets that support it?
>>
>
> Right.
>
Ok.
>> * memory ordering/multi-thread safety:
> That's something to worry about later. :-)
>
Ok.
>> If we unconditionally read from slow_filter_table it could actually
>> reduce the performance (assume slow_filter_table is huge), and might
>> not
>> be legal because we violate
>> the short-circuit evaluation.
>>
>
> Right, speculative loads would require much more analysis to ensure
> safety. This...
2008 Mar 31
0
[LLVMdev] Introducing a branch optimization and prediction pass
...gt;>> equivalent), on targets that support it?
>>>
>>
>> Right.
>>
>
> Ok.
>
>>> * memory ordering/multi-thread safety:
>> That's something to worry about later. :-)
>>
>
> Ok.
>
>>> If we unconditionally read from slow_filter_table it could actually
>>> reduce the performance (assume slow_filter_table is huge), and might
>>> not
>>> be legal because we violate
>>> the short-circuit evaluation.
>>>
>>
>> Right, speculative loads would require much more analysis to ensure...