CMOVcc memory access fixed?

Furs wrote:

Sure, loads take offset to encode as well (from rbp or rsp), but they said 10% loads versus doubling the regs. So smells like bloat to me.

That is a consequence of the diminishing returns of providing more registers. You don't get half the loads by doubling registers. This applies regardless of how you encode the instructions. All architectures experience this same effect.

Going from 1 reg to 2 regs, gives a great boost. Going from 2 to 4 a good boost. From 4 to 8 a moderate boost. etc. ... from 1G regs to 2G regs you get effectively to zero benefit (and probably a big loss from all the overheads).

Not sure what 3 operand instructions are for, considering moves are renamed and cost 0 cycles, not like you have a million moves due to destination operand. But at least it won't bloat the instruction stream since the mov costs bytes to encode as well.

I have a bad feeling Intel will just disable a lot of the current optimizations, expecting you to use their new bullshit instructions/encodings, and so current code will run like shit on their new CPUs.

In that case I will permanently switch to AMD until it changes.

sylware wrote:

CMOVcc memory access fixed?

They are new instructions. So they only exist with REX2.

Not sure what your beef is. If you don't want to "bloat the instruction stream" then simply don't use any of the new instructions or registers. Your code can continue to be "un-bloated" and you don't have to do anything different.

What is your basis for assuming Intel will sabotage themselves by making their CPUs undesirable?

And I'm allowed to complain and explain why they're stupid and I wouldn't use them in the first place.

Itanium

No one said you can't complain. But your "complaint" is silly. You aren't forced to "bloat" your code at all. You can choose to "bloat" your code if you want to, by using R16-R31, or the NDD thing. And you can also choose to never use R16-R31 or NDD. How does adding choice hurt you?

You are moving the goal posts and talking about a different thing. Your suggestion above was that Intel would deliberately make non-REX2 stuff worse. But there is at least one competitor, AMD, so any deliberate reduction in performance would be suicide. That is entirely different form Itanium, a whole new architecture, with no competitor, and no idea if it would be work. So let's get back to the original question before you distracted the discussion, what makes you think Intel will sabotage themselves by deliberately making their stuff worse than their competitor's?

uops.info - Table
                        Alder Lake-P                                            AMD Zen+/2/3/4
Instruction             Lat     TP              Uops    Ports                   Lat     TP      Uops    Ports
LOOP (Rel8)     BASE    2       2.00 / 4.94     7 / 6   1*p0156B+4*p06+1*p1     1       0.50    1       
LOOPE (Rel8)    BASE    [1;3]   3.00 / 6.00     12 / 10 3*p0156B+6*p06+1*p1     1       0.50    1       
LOOPNE (Rel8)   BASE    [1;3]   3.00 / 5.97     12 / 10 3*p0156B+6*p06+1*p1     1       0.50    1

JRCXZ (Rel8)    BASE    0.50 / 0.50     2 / 2   1*p0156B+1*p06                          0.50    1           

Interpreting my post as being about performance is to completely miss the point.

Which results in these instructions still being performant. <snip latency and throughput numbers>

bitRAKE wrote:

Which results in these instructions still being performant. <snip latency and throughput numbers>

How does one not interpret that as a performance measure via latency and throughput numbers?

By reading all the words that came before it.

Do they intentionally have poor performance elsewhere in their processor designs? ...

To make it more concrete, let us look at just control flow instructions. <snip latency and throughput numbers>

If you want to suggest that Intel intends to use REX2/EEVEX to replace all other encodings, then you have to show your evidence. If you did replace everything with REX2/EEVEX then currently you will only get a very small subset of available instructions, and almost none of the "normal" simple instructions.

So your argument that it is like Itanium makes no sense. Itanium was a replacement, not an extension. It didn't work out, but that is the way of things, sometimes things just don't go as planned.

AMD came along and extended x86 with the x86-64. That was a great success. And now Intel have extended x86-64 to this new thing. Suggesting that Intel will sabotage themselves by somehow making their CPUs worse is silly, like I mentioned, it has no basis in reality. Plus the estimates of 10% improvement makes your whole argument moot. If it is "bloat", then it is bloat that works to make stuff better. Embrace the bloat if it works, reject the bloat if it harms.

calling the option to use extended register set as a bloat is invalid.
why didnt someone complain against some instructions set rather than extensions?