Re:The Performance Cost of Integer Overflow Checking
by anewhnaccount on Thursday December 18, 2014 @04:14AM
(#8766572)
I'm pretty rusty so excuse me if I'm spouting nonsense, but I think MRS (read register file) has a dependency on the value of Q (so q/add/sub/clear) and operations which OR a new value with Q (q/add/sub [do q |= 0 or q |= 1) have a dependency on operations which change the register file (MSR). Basically qadd and qusb commute on Q. I'm a bit fuzzy on the details, but I think this means that you just have to stall/predict when there's about to be a branch anyway. Please correct me/clarify if I'm wrong.
Re:The Performance Cost of Integer Overflow Checking
by chrisseaton on Thursday December 18, 2014 @04:20AM
(#8766586)
Yeah you have to predict - so just predict not taken, and treat JO as an uncommon trap. I think that works well in practice.
Re:The Performance Cost of Integer Overflow Checking
by solarexplorer on Thursday December 18, 2014 @04:35AM
(#8766625)
If you assume that reading (and clearing) the Q bit is infrequent, you can do something much cheaper. Because the bit is sticky, the order in which you set it does not matter. And when you need to read (or to clear) the Q bit, you just block the instruction that wants to read/clear until the OoO core is empty.
Re:The Performance Cost of Integer Overflow Checking
by Tuna-Fish on Thursday December 18, 2014 @05:21AM
(#8766724)
An OoO core with speculation has to be able to roll back arbitrary instructions when an earlier instruction causes a visible trap after a later instruction has been executed. Because of this, the core needs to be able to reconstruct the value of Q at any point of execution, even if it's not actually needed then. So the order matters.
Re:The Performance Cost of Integer Overflow Checking
by solarexplorer on Thursday December 18, 2014 @05:33AM
(#8766741)
Good point. So then instead of updating Q out-of-order you could update at commit. You just need to block any instruction that reads Q until the OoO core is empty. This is _much_ cheaper to implement than adding a dependency on all instructions.
This is surprisingly expensive to implement fast and correctly in a modern OoO core. The most likely implementation would end up taking Q as a dependency for every qadd/sub, which would be terrible.
> You can somewhat do the same purely in software with the compiler, but the lack of a "sticky" flag means it'll need to access - and potentially stall - at each point where flags would be overwritten by another ALU instruction.
The jump depends on flags, but by definition has no further dependencies. So long as it's untaken and predicted as untaken the cpu can never stall on it.