It increments rip by one.
You're probably confusing with:
- POP CS being broken and later becoming a prefix
- some opcodes being "reserved NOPs", i.e. reserved without generating #UD. They are used for instructions that may be defined in the future while guaranteeing backwards compatibility, for example new kinds of prefetches. MPX bounds checking instructions were also encoded in reserved NOPs.
It's interesting that a lot of ALU operations occupy four opcodes (memory source/memory destination x byte/word) but 0x84/0x85 and 0x86/0x87 only need two because not only are they commutative, but also 0x84/0x85 do not write to any operands and 0x86/0x87 write to both. So there is no difference between memory as the source or destination operand.
There was a boy A very strange, enchanted boy They say he wandered very far Very far, over land and sea A little shy and sad of eye But very wise was he.
And then one day A magic day he passed my way And while we spoke of many things Fools and kings This he said to me: "The greatest thing you'll ever learn Is just to love and be loved in return."
The actual typical hardware implementation just fetches the next 16-32 bytes from icache, shifts it to the correct alignment, and slams it into a bunch of parallel decoders which each attempts to decode one x86 instruction per byte.
The next cycle, the first 1-6 non-overlapping valid instructions are accepted into a queue for further decoding. The NOP almost certainly takes up space in this queue.
At no point does RIP get incremented by one. There isn't even a single physical RIP register to increment, the CPU is "executing" dozens or even hundreds of RIPs in parallel.