Displaying 7 results from an estimated 7 matches for "checkhazard".
2018 May 09
2
[MachineScheduler] Question about IssueWidth / NumMicroOps
...idgeModel : SchedMachineModel {
// All x86 instructions are modeled as a single micro-op, and SB can
decode 4
// instructions per cycle.
// FIXME: Identify instructions that aren't a single fused micro-op.
let IssueWidth = 4;
, which also seem to indicate (1).
What's more, I see that checkHazard() returns true if '(CurrMOps + uops
> SchedModel->getIssueWidth())'.
This means that the SU will be put in Pending instead of Available based
on the number of microops it uses.
To me this seems like an in-order decoding hazard check, since an OOO
machine will rearrange the microop...
2018 May 14
2
[MachineScheduler] Question about IssueWidth / NumMicroOps
...e basically a single micro-op.
>
> (caveat: there may still be GenericScheduler implementation deficiencies because it is trying to support more scheduling features than we have in-tree targets).
Right now it seems that BeginGroup/EndGroup is only used by SystemZ, or?
I see they are used in checkHazard(), which I actually don't see as
helpful during pre-RA scheduling for SystemZ. Could this be made
optional, or perhaps only done post-RA if target does post-RA
scheduling? SystemZ does post-RA scheduling to manage decoder grouping,
which is where the BeginGroup/EndGroup and IssueWidth/NumMi...
2018 May 15
1
[MachineScheduler] Question about IssueWidth / NumMicroOps
Hi Andy,
>> Right now it seems that BeginGroup/EndGroup is only used by SystemZ,
>> or? I see they are used in checkHazard(), which I actually don't see
>> as helpful during pre-RA scheduling for SystemZ. Could this be made
>> optional, or perhaps only done post-RA if target does post-RA
>> scheduling? SystemZ does post-RA scheduling to manage decoder
>> grouping, which is where the Begi...
2018 May 14
0
[MachineScheduler] Question about IssueWidth / NumMicroOps
...le micro-op.
>
>>
>> (caveat: there may still be GenericScheduler implementation deficiencies because it is trying to support more scheduling features than we have in-tree targets).
> Right now it seems that BeginGroup/EndGroup is only used by SystemZ, or? I see they are used in checkHazard(), which I actually don't see as helpful during pre-RA scheduling for SystemZ. Could this be made optional, or perhaps only done post-RA if target does post-RA scheduling? SystemZ does post-RA scheduling to manage decoder grouping, which is where the BeginGroup/EndGroup and IssueWidth/NumMicroO...
2018 May 09
0
[MachineScheduler] Question about IssueWidth / NumMicroOps
.../ All x86 instructions are modeled as a single micro-op, and SB can decode 4
> // instructions per cycle.
> // FIXME: Identify instructions that aren't a single fused micro-op.
> let IssueWidth = 4;
>
> , which also seem to indicate (1).
>
> What's more, I see that checkHazard() returns true if '(CurrMOps + uops > SchedModel->getIssueWidth())'.
> This means that the SU will be put in Pending instead of Available based on the number of microops it uses.
> To me this seems like an in-order decoding hazard check, since an OOO machine will rearrange the m...
2014 Jan 24
2
[LLVMdev] New machine model questions
Hi Andrew,
I seem to be making good progress on the P5600 scheduler using the new machine model but I've got a few questions about it.
How would you represent an instruction that splits into two micro-ops and is dispatched to two different reservation stations?
For example, I have two reservation stations (AGQ and FPQ). An FPU load instruction is split into a load micro-op which is
2014 Jan 28
3
[LLVMdev] New machine model questions
...lly, rather than multiple parallel uses. This is important for
// in-order machine where the resource consumption is a hazard.
But we could do also add a delay to the resource cycles when the the
processor resource is unbuffered.
- The code in SchedBoundary::bumpNode and SchedBoundary::checkHazard
needs to be updated to increment the cycle accounting for DelayCycles.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140128/76c69b5b/attachment.html>
-------------- next part --------------
A n...