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

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added a comment.

In D98976#2687108 <https://reviews.llvm.org/D98976#2687108>, @dpenry wrote:

> 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.

It sounds like you are making a lot of simplifications though.
Those simplifications might make sense for your particular scenario, but they don't make any sense in the general case.

I understand that part of the goal is to keep algorithmic complexity low, but the resource usage is definitely inaccurate for units that are in multiple groups.
I am not sure about how important this may be for future in-order processor definitions. But it is potentially a significant limitation, and I am not the right person to say that this is the right way to go. If people who work more with in-order processors think that this scenario is not so important/very unlikely for in-order processors, then fine.
I guess the next question would be: where do you plan to document this limitation?

About the number of cycles:
We know exactly the number of resource cycles for each resource unit, so we shouldn't be using the average (at least for resource units).

For groups, I understand your concern about using MAX (I actually meant to write MIN to be honest - I wrote that message very late). However I disagree that it is about computing the average. A group is "available" if at least one of its sub-units is available. Conversely, it is busy if _all_ the sub-units are also busy.
Let say a group G cointains two sub-units {X, Y}; X is consumed for 1cy; Y is consumed for 2cy. Group G is fully booked for exactly 1cy. It becomes available again after 1cy because, by then, X will be also available again. In my comment I should have suggested to use the MIN instead of MAX.

> 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.

Normally you would not need to track uses to solve that issue. It might makes sense for your particular algorithm, but in normal circumstances, the resource consumption is never a function of the users, but only of the resource cycles contributed by the writes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98976