llvm dev - Jul 2013 - [LLVMdev] Questions about MachineScheduler

Hi,

I'm working on defining a SchedMachineModel for the Southern Islands
family of GPUs, and I have two questions related to the
MachineScheduler.

1. I have a resource that can process 15 instructions at the same time.
In the TableGen definitions, should I do:

def HWVMEM   : ProcResource<15>;

or

let BufferSize = 15 in {
def HWVMEM : ProcResource<1>;
}

2. Southern Islands has 256 registers, but there is a significant
performance penalty if you use more than a certain amount.  Do any of
the MachineSchedulers support switching into an 'optimize for register
pressure mode' once it detects register pressure above a certain limit?

Thanks,
Tom

On Jul 22, 2013, at 11:50 AM, Tom Stellard <tom at stellard.net> wrote:
> Hi,
> 
> I'm working on defining a SchedMachineModel for the Southern Islands
> family of GPUs, and I have two questions related to the
> MachineScheduler.
> 
> 1. I have a resource that can process 15 instructions at the same time.
> In the TableGen definitions, should I do:
> 
> def HWVMEM   : ProcResource<15>;
> or
> 
> let BufferSize = 15 in {
> def HWVMEM : ProcResource<1>;
> }
For in-order processors you always want BufferSize=0. In the current generic
scheduler (ConvergingScheduler) it's effectively a boolean that specifies
inorder vs OOO. (I have code that models the buffers in an OOO processor, but I
think it’s too heavy-weight to go in the scheduler. Maybe someday it can be an
analysis tool.)

let BufferSize = 0 {
def HWVMEM   : ProcResource<15>;
}

Now since you’ll want to plugin your own scheduling strategy, how you interpret
the machine model is mostly up to you. What the TargetSchedModel interface does
for you is normalize the resources to processor cycles. This is exposed with
scaling factors (to avoid division): getResourceFactor, getMicroOpFactor,
getLatencyFactor.

So if you have
def HW1   : ProcResource<15>;
def HW2  : ProcResource<3>;

LatencyFactor=15
ResourceFactor(HW1)=1
ResourceFactor(HW2)=5
> 2. Southern Islands has 256 registers, but there is a significant
> performance penalty if you use more than a certain amount.  Do any of
> the MachineSchedulers support switching into an 'optimize for register
> pressure mode' once it detects register pressure above a certain limit?

The code in ConvergingScheduler (I’ll rename it to GenericScheduler soon) is
meant to demonstrate most of the features so developers can copy what they need
into their own strategy, add heuristics and change the underlying data
structures, which often makes sense. You can decide whether you want only
bottom-up, top-down, or both.

For an in-order processor, I think this becomes much simpler. You do away with
most of the complexity in ConvergingScheduler::SchedBoundary and implement a
straightforward reservation table. If it’s fully pipelined then you just count
resource units for the current cycle until one reaches the latency factor. If
it’s not fully pipelined, then you need to define ResourceCycles in the
machine’s SchedWrite definitions and implement a simple reservation table (mark
earliest cycle at which a resource is used for bottom-up scheduling). Some of
this can be made a generic utility, but it’s not much to implement.

Since the strategy defines the priority queues, you can do whatever you want for
your register pressure heuristics. From scanning the full queue each time with
dynamic heuristics, to resorting, to dynamically deferring nodes...

Note that the register pressure tracking is handled outside of the strategy, in
ScheduleDAGMI. So you get this for free without duplication.

However, querying pressure change for a candidate is done by the strategy. The
generic interface, getMaxPressureDelta(), is very clunky now. I’m going to
improve it, but If you’re writing a target specific strategy, it’s probably
easier to directly query a pressure set for a specific register class.

e.g.
RC =TRI->getRegClass(R)
*PSetID = TRI->getRegClassPressureSets(RC)

Now you have a raw pointer right into the machine model’s null terminated array
of PSetIDs that are affected by a register class (targets often have several
overlapping register classes). You can choose one of those sets to track or
track them all. I’m about to commit a patch that will have them sorted by number
of regs in the set, so you can easily grab the largest (end of the list).

Then you can directly query pressure for a specific set...

P = RPTracker.getPressureAfterInst(I)
diff = P[PsetID] - RPTracker.getRegSetPressureAtPos()[PSetID]

Note that how you define your target’s registers can make a big difference in
the pressure set formation. Yours don’t look to bad, but in general remember to
use isAllocatable=0 for any classes that don’t take part in regalloc.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/2f9cf2ff/attachment.html>

On Mon, Jul 22, 2013 at 07:12:04PM -0700, Andrew Trick
wrote:
> 
> On Jul 22, 2013, at 11:50 AM, Tom Stellard <tom at stellard.net>
wrote:
> 
> > Hi,
> > 
> > I'm working on defining a SchedMachineModel for the Southern
Islands
> > family of GPUs, and I have two questions related to the
> > MachineScheduler.
> > 
> > 1. I have a resource that can process 15 instructions at the same
time.
> > In the TableGen definitions, should I do:
> > 
> > def HWVMEM   : ProcResource<15>;
> > or
> > 
> > let BufferSize = 15 in {
> > def HWVMEM : ProcResource<1>;
> > }
> 
> For in-order processors you always want BufferSize=0. In the current
generic scheduler (ConvergingScheduler) it's effectively a boolean that
specifies inorder vs OOO. (I have code that models the buffers in an OOO
processor, but I think it’s too heavy-weight to go in the scheduler. Maybe
someday it can be an analysis tool.)
> 
> let BufferSize = 0 {
> def HWVMEM   : ProcResource<15>;
> }
> 
> Now since you’ll want to plugin your own scheduling strategy, how you
interpret the machine model is mostly up to you. What the TargetSchedModel
interface does for you is normalize the resources to processor cycles. This is
exposed with scaling factors (to avoid division): getResourceFactor,
getMicroOpFactor, getLatencyFactor.
> 
> So if you have
> def HW1   : ProcResource<15>;
> def HW2  : ProcResource<3>;
> 
> LatencyFactor=15
> ResourceFactor(HW1)=1
> ResourceFactor(HW2)=5
> 
> > 2. Southern Islands has 256 registers, but there is a significant
> > performance penalty if you use more than a certain amount.  Do any of
> > the MachineSchedulers support switching into an 'optimize for
register
> > pressure mode' once it detects register pressure above a certain
limit?
> 
> 
> The code in ConvergingScheduler (I’ll rename it to GenericScheduler soon)
is meant to demonstrate most of the features so developers can copy what they
need into their own strategy, add heuristics and change the underlying data
structures, which often makes sense. You can decide whether you want only
bottom-up, top-down, or both.
> 
> For an in-order processor, I think this becomes much simpler. You do away
with most of the complexity in ConvergingScheduler::SchedBoundary and implement
a straightforward reservation table. If it’s fully pipelined then you just count
resource units for the current cycle until one reaches the latency factor. If
it’s not fully pipelined, then you need to define ResourceCycles in the
machine’s SchedWrite definitions and implement a simple reservation table (mark
earliest cycle at which a resource is used for bottom-up scheduling). Some of
this can be made a generic utility, but it’s not much to implement.
> 
> Since the strategy defines the priority queues, you can do whatever you
want for your register pressure heuristics. From scanning the full queue each
time with dynamic heuristics, to resorting, to dynamically deferring nodes...
> 
> Note that the register pressure tracking is handled outside of the
strategy, in ScheduleDAGMI. So you get this for free without duplication.
> 
> However, querying pressure change for a candidate is done by the strategy.
The generic interface, getMaxPressureDelta(), is very clunky now. I’m going to
improve it, but If you’re writing a target specific strategy, it’s probably
easier to directly query a pressure set for a specific register class.
> 
> e.g.
> RC =TRI->getRegClass(R)
> *PSetID = TRI->getRegClassPressureSets(RC)
> 
> Now you have a raw pointer right into the machine model’s null terminated
array of PSetIDs that are affected by a register class (targets often have
several overlapping register classes). You can choose one of those sets to track
or track them all. I’m about to commit a patch that will have them sorted by
number of regs in the set, so you can easily grab the largest (end of the list).
> 
> Then you can directly query pressure for a specific set...
> 
> P = RPTracker.getPressureAfterInst(I)
> diff = P[PsetID] - RPTracker.getRegSetPressureAtPos()[PSetID]
> 
> Note that how you define your target’s registers can make a big difference
in the pressure set formation. Yours don’t look to bad, but in general remember
to use isAllocatable=0 for any classes that don’t take part in regalloc.
> 
Hi Andy,

Thanks for the response, this is really helpful.

-Tom