qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 0/5] tcg conditional set, round 4
Date: Mon, 21 Dec 2009 12:28:03 -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/21/2009 01:13 AM, Laurent Desnogues wrote:
The question for the generalized movcond is how useful is it?
Which front-ends would need it and would the cost to generate
code for it on some (most?) back-ends be amortized?

... Any front end that has a conditional move instruction?
Sparcv9, Mips32, Alpha, ARM...

That said, I think the *biggest* gains are to be had because with movcond -- at least on some targets -- we can have one BB per TB, and avoid any intermediate spilling of global registers back to memory.

My guess (I use that word given that I didn't do any benchmark
to sustain my claim) is that your implementation is too complex.

Too complex for what? The message against which you are quoting has an implementation of 2 lines.

Of course setcond can be implemented in terms of movcond,
but my guess (again that word...) is that setcond could be
enough and even faster in most cases.

To implement condition codes, yes, to implement compare instructions (e.g. mips slt, alpha cmp{eq,lt,lte}), yes. To implement conditional moves, no. At least not without using 5 instructions where 1 would suffice.

Regarding your patches, I would like to see setcond put in
mainline with a simplified version for i386.

Again, simplified from what?  The last setcond implementation was 2 lines.


r~




reply via email to

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