It's not an instruction, it's a macroop that gets executed as microops.
Macroops can't be non-speculative since they aren't actually executed.
The microops can be non-speculative (and the one in question probably
is) but that doesn't help with branch misprediction later in the same
macroop.
Gabe
On 11/13/11 16:20, Nilay Vaish wrote:
> 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 issue exists today and
>> it's just luck that it works currently.
>>
>> Looking at your list I imagine you should be able to recover most
>> things from the dyninst, however I don't know if that is actually the
>> case. Excepted that the squashing mechanisms should be cleaned up,
>> I'm not sure how that is actually going to solve the problem. Don't
>> we currently send back the instruction? With the current instructions
>> can't you figure out the macro-op it belongs to?
>>
>> Ali
>>
>>
>>
>> On Nov 13, 2011, at 5:40 PM, Gabe Black wrote:
>>
>>> Hey folks. Ali has had a change out for a while ("Fix several Branch
>>> Predictor issues") which improves branch predictor performance
>>> substantially but breaks X86_FS on O3. It turns out the problem is that
>>> an instruction is started which returns from kernel to user level
>>> and is
>>> microcoded. The instruction is fetched from the kernel's address space
>>> successfully and starts to execute, along the way dropping down to user
>>> mode. Some microops later, there's some microop control flow which O3
>>> mispredicts. When it squashes the mispredict and tries to restart, it
>>> first tries to refetch the instruction involved. Since it's now at user
>>> level and the instruction is on a kernel level only page, there's a
>>> page
>>> fault and things go downhill from there.
>>>
>>> I partially implemented a solution to this before where O3 reinstates
>>> the macroop it had been using when it restarts fetch. The problem here
>>> is that the path this kind of squash takes doesn't pass back the right
>>> information, and my attempts to fix that have been unsuccessful. The
>>> code that handles squashing in O3 is too complex, there's too much
>>> going
>>> in all directions, it's not always very clear what affect a change will
>>> have in unrelated situations, or which callsites are involved in a
>>> particular type of fault.
>>>
>>> To me, it seems like the first step in fixing this problem is to clean
>>> up how squashes are handled in O3 so that they can be made to
>>> consistently handle squashes in non-restartable macroops.
>>>
>>> Without having really dug into the specifics, I think we only need two
>>> pieces of information when squashing, a pointer to the guilty
>>> instruction and whether execution should start at or after it. It would
>>> start at it if the instruction needed to be reexecuted due to a memory
>>> dependence violation, for instance, and would start after it for
>>> faults,
>>> interrupts, or branch mispredicts. Any other information that's needed
>>> like sequence numbers or actual control flow targets can be retrieved
>>> from the instructions where needed without having to split everything
>>> out and pass them around individually.
>>>
>>> Is there any obvious problem with doing things this way? I don't think
>>> I'll personally have a lot of time to dedicate to this at the very
>>> least
>>> in the short term, but I wanted to get the conversation going so we
>>> know
>>> what to do when somebody has a chance to do it.
>>>
>>> Gabe
>>> _______________________________________________
>>> gem5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>>
>>
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
