qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] tcg conditional set/move, round 3


From: Richard Henderson
Subject: Re: [Qemu-devel] tcg conditional set/move, round 3
Date: Sat, 19 Dec 2009 08:19:32 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0

On 12/19/2009 05:03 AM, Aurelien Jarno wrote:
- For the movcond instruction, is there a real use for vtrue and vfalse
   values? Most CPU actually implement a version with one value.
   Implementing it with two values moves complexity within the arch
   specific tcg code.

The reason I added both is that rather than force TCG to insert extra moves in order to always match VFALSE with DEST, I could have the backend invert the condition if VTRUE happened to match DEST already.

I suppose it would be possible to tweek the TCG register allocator to understand such commutative operations. That seemed harder, but perhaps it really isn't considering that inversion code has to be replicated across all the targets. It's certainly something to think about.

- Do we really want to make movcond mandatory? It can be easily
   implemented using setcond, and, or instructions.

I think so. In that every host does have something useful to emit that's better than the generic fallback, and we'll quickly have implementations for each.

- I am not sure using xor and followed by setcc *conditionally* instead
   of a movzb after setcc is a good idea. The two instructions are
   supposed to be executed at the same speed, and time spent in code
   generation is not negligeable.

I can certainly remove that bit if you insist.

- Pay attention to the coding style, there are a few cases of if
   without {}.

Ok. I try to remember, but it's at odds with my usual style, so please understand momentary lapses.

A final comment, would it be possible to split setcond and movcond in
different patches? setcond looks ready to go, there are probably some
more concerns/comments about movcond.

Ok.


r~




reply via email to

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