llvm dev - Feb 2018 - [VLIW Scheduler] Itineraries vs. per operand scheduling

Hi Krzysztof,

2018-02-08 13:32 GMT+08:00 Andrew Trick via llvm-dev <
llvm-dev at lists.llvm.org>:
>
>
> On Feb 4, 2018, at 9:15 AM, Yatsina, Marina via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> What is the best way to model a scheduler for a VLIW in-order architecture?
> I’ve looked at the Hexagon and R600 architectures and they are using
> itineraries. I wanted to understand the benefit in using itineraries over
> the per operand scheduling.
>
> ​Do you have time to give comment on why Hexagon still use itineraries,
rather than switching to per operand scheduling like ARM does? I really
like to hear your opinion.

Thanks.​ :-)

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/92667e0c/attachment.html>

We have a two different dimensions for each instruction: slot 
assignments, and operand timings. These two are unrelated to each other, 
and also each (or both) can change for any given instruction from one 
architecture version to the next.

The main concern for us was which of these mechanisms contains all the 
information that we need. We cannot express all the scheduling details 
by hand, and majority of it was auto-generated anyway. I don't know if 
the new model has all the required pieces of information, but we've been 
using itineraries for a while, and we stuck with them.

The short answer is "because it works", but it's not meant to
imply that
nothing else would.

-Krzysztof


On 2/8/2018 8:49 AM, 陳韋任 wrote:
> Hi Krzysztof,
> 
> 2018-02-08 13:32 GMT+08:00 Andrew Trick via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>:
> 
> 
> 
>>     On Feb 4, 2018, at 9:15 AM, Yatsina, Marina via llvm-dev
>>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>>     Hi,____
>>     __ __
>>     What is the best way to model a scheduler for a VLIW in-order
>>     architecture?____
>>     I’ve looked at the Hexagon and R600 architectures and they are
>>     using itineraries. I wanted to understand the benefit in using
>>     itineraries over the per operand scheduling.
> 
> ​Do you have time to give comment on why Hexagon still use itineraries, 
> rather than switching to per operand scheduling like ARM does? I really 
> like to hear your opinion.
> 
> Thanks.​ :-)
> 
> -- 
> Wei-Ren Chen (陳韋任)
> Homepage: https://people.cs.nctu.edu.tw/~chenwj
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

> On Feb 8, 2018, at 11:40 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> We have a two different dimensions for each instruction: slot assignments,
and operand timings. These two are unrelated to each other, and also each (or
both) can change for any given instruction from one architecture version to the
next.
> 
> The main concern for us was which of these mechanisms contains all the
information that we need. We cannot express all the scheduling details by hand,
and majority of it was auto-generated anyway. I don't know if the new model
has all the required pieces of information, but we've been using itineraries
for a while, and we stuck with them.
> 
> The short answer is "because it works", but it's not meant to
imply that nothing else would.
> 
> -Krzysztof
That reminds me, in the new model, there are two different ways to define issues
constraints:

ARMScheduleSwift has two ALU pipes. Some instructions can issue on either one,
so we define a superset “P01” resource like this:
  def SwiftUnitP01 : ProcResource<2>; // ALU unit.
  def SwiftUnitP0 : ProcResource<1> { let Super = SwiftUnitP01; } // Mul
unit.
  def SwiftUnitP1 : ProcResource<1> { let Super = SwiftUnitP01; } // Br
unit.

Haswell allows an instruction to issue an any arbitrary set of ports, so it uses
groups:

def HWPort1 : ProcResource<1>;
def HWPort2 : ProcResource<1>;
def HWPort3 : ProcResource<1>;
def HWPort4 : ProcResource<1>;
def HWPort5 : ProcResource<1>;
def HWPort6 : ProcResource<1>;
def HWPort7 : ProcResource<1>;

// Many micro-ops are capable of issuing on multiple ports.
def HWPort01  : ProcResGroup<[HWPort0, HWPort1]>;
def HWPort23  : ProcResGroup<[HWPort2, HWPort3]>;
def HWPort237 : ProcResGroup<[HWPort2, HWPort3, HWPort7]>;
…

IIRC: they’re modeled the same way and ProcRegGroup is just computing superset
relations for you.
And an instruction on pipe/port “01” can issue on either dynamically, so a
subsequent pipe/port “0” instruction could issue in the same cycle.

For something like slot assignments, I would be tempted to write an small
independent state machine as part of the hazard checker, then use the machine
model (either itinerary or per-operand) just for operand timings.

-Andy
> On 2/8/2018 8:49 AM, 陳韋任 wrote:
>> Hi Krzysztof,
>> 2018-02-08 13:32 GMT+08:00 Andrew Trick via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>:
>>>    On Feb 4, 2018, at 9:15 AM, Yatsina, Marina via llvm-dev
>>>    <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>> 
>>>    Hi,____
>>>    __ __
>>>    What is the best way to model a scheduler for a VLIW in-order
>>>    architecture?____
>>>    I’ve looked at the Hexagon and R600 architectures and they are
>>>    using itineraries. I wanted to understand the benefit in using
>>>    itineraries over the per operand scheduling.
>> ​Do you have time to give comment on why Hexagon still use itineraries,
rather than switching to per operand scheduling like ARM does? I really like to
hear your opinion.
>> Thanks.​ :-)
>> -- 
>> Wei-Ren Chen (陳韋任)
>> Homepage: https://people.cs.nctu.edu.tw/~chenwj
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev