Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 14, 2013 4:44 pm wrote:
> rwessel (robertwessel.delete@this.yahoo.com) on February 14, 2013 4:14 pm wrote:
> >
> > As I mentioned elsewhere in this thread, compare-and-branch is an excellent choice, but I'd really
> > also want something to do a compare without a branch. You want to be able to combine some simple
> > tests without a branch, and to do some limited predication. Not always, but there are definitely
> > times to want those. Compare-and-set-GPR seems like a better choice there than actual CCs.
>
> There's nothing wrong with having a flags register. It's in many ways much superior to the alternatives.
>
> In contrast, multiple CC registers are just stupid.

Isn't it true that the following code could run faster with 2 CC registers:

if a==b && c==d { ... }

>It just makes things actively worse for renaming,
> it's horrible for instruction encoding, and the win is basically zero. The argument for multiple
> CC's is just stupid too, and seems to be about idiotic in-order machines. Let them die already,
> and accept the fact that it's much better to have multiple CC's through renaming.
>
> And compare-and-branch may be "clean", but again, it's just a instruction encoding nightmare, since you *do*
> need to also be able to compute the value or do things like conditional moves, for value setting etc etc.
>
> So a (single) flags register is just fine. It works. The flags make it easy to do different things depending
> on the conditional - setting values, conditional moves, branches, whatever. They have no serious downsides,
> and having a separate register space is more flexible and not really complicated.
>
> There is not really any sane argument against having a flags register.
>
> Now, you can certainly do flags registers wrong. The x86 model where some instructions write some bits
> but not all is just bad, and forces the microarchitecture to either rename it basically bit-by-bit, or
> not rename it at all. That's just wrong, and a mistake. But that's just a particular detail of an odd
> implementation of having a condition flags register, it shouldn't be seen as "flags are evil".
>
> And the x86 one is still better than the abortion that is the PowerPC crap. The fact that anybody brought
> the idiotic powerpc model as an example of how to do things "right" is just sad. What a crock.
>
> And putting the condition codes in GPRs (alpha) may look really clean and allows some nice combined conditionals,
> but the upside just isn't there. It doesn't really generate better code: you win some, you lose some.
>
> Linus