Apparently it was just some stale swig files. I've had problems with
that sort of thing before and thought I had already tried deleting what
are usually the problem, but I guess I didn't do that successfully.
Gabe
On 11/08/11 11:54, Steve Reinhardt wrote:
Well, to start with a disclaimer, this
*
build/SPARC_FS/tests/opt/long/80.solaris-boot/sparc/solaris/t1000-simple-atomic
FAILED!
* build/X86_SE/tests/opt/long/70.twolf/x86/linux/o3-timing FAILED!
* build/X86_SE/tests/opt/long/10.mcf/x86/linux/o3-timing FAILED!
*
I think this bug is just latently in the code right now and the branch
predictor change runs into it (this patch causes that branch to be
mispredicted). In any case I think the issue exists today and it's just luck
that it works currently.
Looking at your list I imagine you should be able to
Should not such an instruction be executed non-speculatively?
--
Nilay
On Sun, 13 Nov 2011, Ali Saidi wrote:
I think this bug is just latently in the code right now and the branch
predictor change runs into it (this patch causes that branch to be
mispredicted). In any case I think the
Yes, this is an existing bug and the branch predictor just pokes things
in the right way to expose it. The macroop isn't passed back in this
particular case, and with the code the way it is, it's difficult to even
tell that that's the case, let alone how to fix it. Cleaning things up
won't fix the
I'd like to understand the issue a little better before commenting on a
solution.
Gabe, when you say instruction in your original description, do you mean
micro-op?
It seems to me that the fundamental problem is that we're trying to undo
the effects of a non-speculative micro-op, correct? So
No, we're not trying to undo anything. An example might help. Lets look
at a dramatically simplified version of iret, the instruction that
returns from an interrupt handler. The microops might do the following.
1. Restore prior privilege level.
2. If we were in kernel level, skip to 4.
3. Restore
Thanks for the more detailed explanation... that helped a lot. Sounds to
me like you're on the right track.
Steve
On Sun, Nov 13, 2011 at 8:20 PM, Gabe Black gbl...@eecs.umich.edu wrote:
No, we're not trying to undo anything. An example might help. Lets look
at a dramatically simplified
Well, I still don't get it. Do out-of-order CPUs speculate on iret? If
iret is to be executed non-speculatively, I would expect micro-ops that
are part of iret are executed non-speculatively.
--
Nilay
On Sun, November 13, 2011 11:14 pm, Steve Reinhardt wrote:
Thanks for the more detailed
On Thu, 10 Nov 2011, Steve Reinhardt wrote:
Whoops, that's just an oversight. I just updated the bullet at the bottom
to point to the CAN paper. If we want to do something else too, that's
fine with me, but at least the immediate issue is taken care of.
Steve
On Thu, Nov 10, 2011 at 8:30
10 matches
Mail list logo
