llvm dev - Aug 2016 - Question about modeling of a processor

Hi

I am working on modeling a processor with resource descriptors, to be used
by Machine Scheduler.

IIUC, Currently we can model the following aspects of a processor

1- If we have a # of processors resources of the same kind, we can say that
an insn will use one of the units of that resource kind.
2- We can say that an insn will use multiple units of resources of the same
or different kinds in parallel or sequentially.

What I need though is to say that an insn can use one unit of two resources
of different kinds (but not both). Is there any way to express this? I
thought ProcResGroup is introduced for this purpose, but looking at how it
is used, and also looking at the output of tablegen -gen-subtarget I am not
able to use it to achieve this goal.

Thanks
Ehsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160824/9a076110/attachment.html>

I have not been able to figure out what exactly ProcResGroup (which is
defined in include/llvm/Target/TargetSchedule.td) does. Let me explain with
an example. I appreciate any help.

I have the following in the .td file (among other things):

  def ALU : ProcResource<4>;
  def DP : ProcResource<4>;

  def TestGroup : ProcResGroup<[ALU, DP]>;

def P9_Test_76C : SchedWriteRes<[TestGroup]> {
    let Latency = 76;
    let ResourceCycles = [62];
  }

  def : ItinRW<[P9_Test_76C, IP_EXEC_1C, DISP_1C, DISP_1C], [IIC_IntSimple,
                                         IIC_IntGeneral]>;


Then when I look at the output of llvm-tblgen -gen-subtarget

I see the following:

// {Name, NumUnits, SuperIdx, IsBuffered}
static const llvm::MCProcResourceDesc P9ModelProcResources[] = {
..........
  {DBGFIELD("TestGroup")       8, 0, -1}  // #16
};

I believe we have 8 units of TestGroup because using TestGroup means using
ALU or DP and we have four of each.

I also see

// {Name, NumMicroOps, BeginGroup, EndGroup, WriteProcResIdx,#,
WriteLatencyIdx,#, ReadAdvanceIdx,#}
static const llvm::MCSchedClassDesc P9ModelSchedClasses[] = {
.................
  {DBGFIELD("IIC_IntSimple")      1, false, false,  1, 3,  1, 4,  0,
0}, //
#1
};

and

// {ProcResourceIdx, Cycles}
extern const llvm::MCWriteProcResEntry PPCWriteProcResTable[] = {
......
  {16, 62}, // #3
......
}

All of this makes sense, except that I do not see anything in the output of
tablegen that creates a relationship between TestGroup, ALU and DP. Even if
there is such a mapping somewhere else that I have missed, I cannot see how
it is exploited in MachineScheduler.cpp. Because what we do there, is the
following:

-- for a scheduled insn loop over all its WriteProcRes (highlighted in
blue). Then from that extract ProcResourceIdx (highlighted in red). From
there we update the usage of this ProcResource. I expected to see some
connection to ALU and DP when we update resource usage.

I have looked at the commits that added this construct as well, but
couldn't figure out the answer to my question.

Thanks
Ehsan


On Wed, Aug 24, 2016 at 2:45 PM, Ehsan Amiri <ehsanamiri at gmail.com>
wrote:
> Hi
>
> I am working on modeling a processor with resource descriptors, to be used
> by Machine Scheduler.
>
> IIUC, Currently we can model the following aspects of a processor
>
> 1- If we have a # of processors resources of the same kind, we can say
> that an insn will use one of the units of that resource kind.
> 2- We can say that an insn will use multiple units of resources of the
> same or different kinds in parallel or sequentially.
>
> What I need though is to say that an insn can use one unit of two
> resources of different kinds (but not both). Is there any way to express
> this? I thought ProcResGroup is introduced for this purpose, but looking at
> how it is used, and also looking at the output of tablegen -gen-subtarget I
> am not able to use it to achieve this goal.
>
> Thanks
> Ehsan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160919/cc69490c/attachment.html>