qemu-devel
[Top][All Lists]
Advanced

[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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]