Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 27, 2022 10:13 am wrote:
> Jörn Engel (joern.delete@this.purestorage.com) on July 26, 2022 10:17 am wrote:
> >
> > Note that compilers do a surprisingly poor job here, at least until recently.
>
> I think the "source in %rdx" is somewhat unusual (normally %rax is the special register,
> with obviously %cl for shift counts, and %rdx:%rax being special for the old multiply),
> and most x86 compilers end up having been tuned for different register use.
>
> And gcc in particular tends to want to use fixed register pairs even when the instructions
> don't require it, so if you do 128-bit math - which you obviously are doing if you're using
> 'mulx' - gcc often wants to pair up %rax/%rdx, with %rdx being the high word.
>
> So even when the hardware doesn't have any particular register pairing preferences, gcc
> definitely does, and then uses odd stack spills etc as a way to move things around.
>
> I don't know why mulx does that unusual source, but I assume that Intel did some example loops
> and that it ends up working better when you get it right (possibly exactly because other ops
> want to use %rax for its special use - including that regular old-fashioned 'mul').

Just a note/idea that came to my mind while reading your post: If a CPU can execute 2+ register moves per clock and 1 ALU instruction per clock (3+ operations per clock in total), then the operands of all ALU instructions can be implicit/fixed registers, _without causing_ a major performance degradation. Some random examples:


MOV ...; ADD; MOV ... // The ADD is always %r5, %flags2 := %r3 + %r4
MOV ...; MUL; MOV ... // The MUL is always %r8_%r3 := %r10 * %r0


where %flags2 is a flag register (this totally-hypothetical CPU has multiple flag registers). The MUL instruction has no %flagsN destination register because the MUL cannot overflow.

It is likely that in such an instruction set architecture, a single MOV instruction would be encoding multiple register moves, for example "MOV %r10 := %r3, %r6 := %r13, %r3 := %flags2" where %r3, %r13, %flags2 are read atomically and %r10, %r6, %r3 are _then_ written atomically (that is: the combination %r10 := %r3 and %r3 := %flags2 isn't a write-after-read hazard nor a read-after-write hazard).

(Because you are usually overly critical of ideas that do not match your worldview, I am forced to note that: The above paragraphs are just an idea .... if the idea happens to mismatch your worldview there is no need for you to start criticizing how "fundamentally bad" the idea is in case you decide to write a response to my post. Thanks.)

-atom