[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/7] tcg: Optimize add2 + sub2
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [PATCH 2/7] tcg: Optimize add2 + sub2 |
Date: |
Mon, 01 Oct 2012 11:36:14 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 |
On 2012-09-30 00:04, Blue Swirl wrote:
>> We can't do complete constant folding because we lack "mov2",
>> > or the ability to insert opcodes in the stream. But we can
>> > at least canonicalize add2 operand ordering and simplify
>> > add2 to add when the lowpart adds a constant 0.
> Couldn't we introduce add2_part1 and add2_part2, the latter being nop
> for architectures that don't need it?
Possibly. It certainly would be easy to model these as addcc + addx on
targets like sparc where CC never gets clobbered during moves.
I'm a bit worried about i386 though, since loading 0 wants to use xor
and clobber the flags. We could possibly work around this by taking
care of the constant loading for add2_part2 manually. E.g.
{ INDEX_op_add2_part2, { "r", "ri", "ri" } }
if (args[2] == args[0] && !const_args[2]) {
// swap arg1 arg2
}
if (const_args[1]) {
mov $args[1], args[0]
} else {
mov args[1], args[0]
}
adcl args[2], args[0]
which means that tcg_out_movi will not have to be called in between.
It's all a bit fragile though.
That said, I do wonder if having a synthetic mov2{rr,ri,ii} opcodes
isn't just easier. That could be broken up into two moves by tcg.c
without the backends having to care about it.
r~