[PATCH] D98976: [CodeGen] Use ProcResGroup information in SchedBoundary

[David Penry via Phabricator via llvm-commits]

dpenry added a comment.

In D98976#2686840 <https://reviews.llvm.org/D98976#2686840>, @andreadb wrote:

> I had another look at the patch.
>
> The resource cycle computation doesn't look correct. I think that there is a bit of confusion on how resource cycles of a group are allocated to the underlying sub-units. See my comments below.

I didn't deal with resources assigned to more than one group as an intentional simplification; I had intended to document that.  The code can certainly be made to accommodate that with more complexity.

Again as a simplification there is an assumption of equal cycle usages among members of a group.  You could also think of it as finding the average number of cycles the resource group is used. I wouldn't mind make it more exact, but max is not going to give the right answer for true hazarding; it would need to really recreate the original structure of uses (e.g. 1 instance for 2 cycles in parallel with 1 instance for 1 cycle).  Not impossible, but more complexity.

However, there must be a tracking of how many uses have been made of a resource group by its members.  The whole point of this exercise is to be able to model the simultaneous use of multiple instances of a resource; the resource group represents this resource.  If we don't track them in some way, we can't use the right number of them.



================
Comment at: llvm/lib/CodeGen/MachineScheduler.cpp:2199
+      if (ResGrpID && !SchedModel->getProcResource(ResGrpID)->BufferSize) {
+        GroupAdjustments[ResGrpID]++;
+        HasResGroup = true;
----------------
andreadb wrote:
> Why do you need to keep track of the number of uses?
> 
> The number of users of a group isn't important.
> The only thing that matters for the resource latency computation is how many cycles are contributed by the sub-units. See my comment below.
> Why do you need to keep track of the number of uses?
> 
> The number of users of a group isn't important.
> The only thing that matters for the resource latency computation is how many cycles are contributed by the sub-units. See my comment below.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98976/new/

https://reviews.llvm.org/D98976