[PATCH PR62011]
Yuri Rumyantsev
ysrumyan@gmail.com
Thu Aug 14 14:42:00 GMT 2014
For example, for the first loop for attached test-case we do not
prepend xor to popcnt because of using destination register:
.L23:
leal 1(%rdx), %ecx
popcntq (%rbx,%rax,8), %rax
leal 2(%rdx), %r8d
popcntq (%rbx,%rcx,8), %rcx
addq %rax, %rcx
leal 3(%rdx), %esi
xorq %rax, %rax
popcntq (%rbx,%r8,8), %rax
addq %rax, %rcx
xorq %rax, %rax
popcntq (%rbx,%rsi,8), %rax
addq %rax, %rcx
leal 4(%rdx), %eax
addq %rcx, %r14
movq %rax, %rdx
cmpq %rax, %r12
ja .L23
2014-08-14 18:06 GMT+04:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
> 2014-08-14 18:00 GMT+04:00 Alexander Monakov <amonakov@ispras.ru>:
>>
>>
>> On Thu, 14 Aug 2014, Yuri Rumyantsev wrote:
>>
>>> Hi All,
>>>
>>> Here is a fix for PR 62011 - remove false dependency for unary
>>> bit-manipulation instructions for latest BigCore chips (Sandybridge
>>> and Haswell) by outputting in assembly file zeroing destination
>>> register before bmi instruction. I checked that performance restored
>>> for popcnt, lzcnt and tzcnt instructions.
>>
>> I am not an x86 reviewer, but one thing looks a bit superfluous to me:
>>
>>> +/* Retirn true if we need to insert before bit-manipulation instruction
>> note typo^
>>
>>> + zeroing of its destination register. */
>>> +bool
>>> +ix86_avoid_false_dep_for_bm (rtx insn, rtx operands[])
>>> +{
>>> + unsigned int regno0;
>>> + df_ref use;
>>> + if (!TARGET_AVOID_FALSE_DEP_FOR_BM || optimize_function_for_size_p (cfun))
>>> + return false;
>>> + regno0 = true_regnum (operands[0]);
>>> + /* Check if insn does not use REGNO0. */
>>> + FOR_EACH_INSN_USE (use, insn)
>>> + if (regno0 == DF_REF_REGNO (use))
>>> + return false;
>>> + return true;
>>> +}
>>
>> The loop is to prevent adding the xor when the dest operand is also the source
>> operand. Looks like a simpler "reg_or_subregno (operands[0]) ==
>> reg_or_subregno (operands[1])" could be used here, as long as the assumption
>> that this is called only for two-operand instruction holds?
>
> This wouldn't cover memory operand case.
>
> Ilya
>
>>
>> Alexander
More information about the Gcc-patches
mailing list