This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH,x86] Fix combine for condditional instructions.
On Thu, Dec 13, 2012 at 3:23 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
> Hi Guys,
>
> The patch proposed by Uros is useless since we don't have free scratch
> register to do splitting of memory operand:
>
> ;; regs ever live 0[ax] 1[dx] 2[cx] 3[bx] 4[si] 5[di] 6[bp] 7[sp] 17[flags]
>
> ...
>
> (insn 96 131 132 7 (set (reg/v/f:SI 6 bp [orig:70 trie_root ] [70])
> (if_then_else:SI (ne (reg:CCZ 17 flags)
> (const_int 0 [0]))
> (mem/f:SI (plus:SI (reg/v/f:SI 0 ax [orig:70 trie_root ] [70])
> (const_int 12 [0xc])) [2 trie_root_23->rlink+0 S4 A32])
> (reg/v/f:SI 6 bp [orig:70 trie_root ] [70])))
> routelookup/route_lookup.c:639 940 {*movsicc_noc}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (expr_list:REG_DEAD (reg/v/f:SI 0 ax [orig:70 trie_root ] [70])
> (nil))))
>
> How we can cope with this? I still assume that we can apply my patch
> with additional check on optimization for speed.
What's the important benchmark you are register-starved for?
Richard.
> Best regards.
> Yuri.
>
> 2012/12/12 Richard Henderson <rth@redhat.com>:
>> On 12/12/2012 10:32 AM, Uros Bizjak wrote:
>>> Please check the attached patch, it implements this limitation in a correct way:
>>> - keeps memory operands for -Os or cold parts of the executable
>>> - doesn't increase register pressure
>>> - handles all situations where memory operand can propagate into RTX
>>
>> I agree this is the right way to attack this problem.
>>
>>
>> r~