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~
