Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I found a bug in Intel Skylake processors

gallium.inria.fr

Post reply on HN
Print view View original

1–10 of 104 posts

Re: I found a bug in Intel Skylake processors

#3

Post by raverbashing »

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.

Re: I found a bug in Intel Skylake processors

#4

Post by barrkel »

raverbashing wrote: post #3

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.

AH is no more of an anachronism in 64-bit code than it was in 32-bit code; AL, AH, AX, EAX, RAX; all bit slices of the same register. The addition of RAX doesn't change the fact that AH is still a bit weird (it's the only one that doesn't include the low bits of the total register).

Re: I found a bug in Intel Skylake processors

#5

Post by wereHamster »

raverbashing wrote: post #3

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.

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.

Re: I found a bug in Intel Skylake processors

#7

Post by willvarfar »

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 caches or resources." ... "capable of detecting loops up to 64 µOPs per thread". https://en.wikichip.org/wiki/intel/microarchitectures/skylak...

> So maybe the microcode update just shuts off the loopback detector.

https://groups.google.com/d/msg/comp.arch/UkO4Z2FT18c/7YlC0a...

So if the bug is in the loop-detector, and the patch possibly disables it rather than fixes it, then does anyone have any before-and-after performance stats?

Re: I found a bug in Intel Skylake processors

#8

Post by raverbashing »

wereHamster wrote: post #5
raverbashing wrote: post #3

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.

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"
Post reply on HN