11–20 of 104 posts
GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.
Earlier quoted context omitted.
It's not obvious. If it was then GCC would not do it. Please don't use the word 'obvious' when it is to you but not to the majority of population.
It is obvious, though I meant "obvious and correct" not "obviously correct"
rr can often be a time-saver in situations by providing deterministic replays up to the point of a crash, whereas coredump analysis is a single retrospective snapshot.
There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to support instructions that address the second-to-last byte of a register (eg. %ah) while keeping the rest of the register 'unchanged', which of course means making a complete mess of the code execution path.
The only reason this crap still exists is to keep Windows users' ability to run random EXE and DLL files from the 90s, if not random COM files from the 80s, at the expense of CPU cost, stability, and correctness for everyone else (such as the OCaml developers and users who ran into this bug.)
GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.
Do you know for a fact that Clang's code is faster here, i.e., have you measured it on actual hardware? Armchair performance estimation about "the potential" for something is often wrong...
> I worked from the executable provided by SIOU, first interactively under GDB (but it nearly drove me crazy, as I had to wait sometimes one hour to trigger the crash again), then using a little OCaml script that ran the program 1000 times and saved the core dumps produced at every crash. rr can often be a time-saver in situations by providing deterministic replays up to the point of a crash, whereas coredump analysi…
A comp.arch poster said: > The errata refers to the problem showing up on short loops of less than 64 instructions that use AH, BH, CH or DH. > Looking at the Skylake microarch, the instruction decode queue is 128 uOps thread, 2*64 uOps when threaded. The Loop Stream Detector "can stream the same sequence of µOPs directly from the IDQ continuously without any additional fetching, decoding, or utilizing additional cac…
I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…
It's lazy to the point of dishonesty to act as if Microsoft is the only one with decades of accumulated code.
Earlier quoted context omitted.
It's not obvious. If it was then GCC would not do it. Please don't use the word 'obvious' when it is to you but not to the majority of population.
It is obvious, though I meant "obvious and correct" not "obviously correct"
More bluntly, before now wouldn't most people have said it was “obvious” that Intel would support their own documented features?
Earlier quoted context omitted.
It is obvious, though I meant "obvious and correct" not "obviously correct"
Who can clarify? Google says: Qbvious - easily perceived or understood; clear, self-evident, or apparent.