[PATCH] D53055: [MCA] Limit the number of bytes fetched per cycle.

[Clement Courbet via Phabricator via llvm-commits]

courbet added a comment.

Hi Andrea,

> There is already bug https://bugs.llvm.org/show_bug.cgi?id=36665, which is about adding support for simulating the hardware frontend logic.
>  I know that @courbet  and his team would like to work on it. So, you can probably try to work with them on this.
>  Unfortunately, that bugzilla must be updated. There is not enough information there (I suggested to send a detailed RFC upstream in case).
> 
> I strongly suggest you/your team/Clement's team to work together on that task. I am afraid that people may be working on the same tasks in parallel.. That has to be avoided.
>  You can use that bugzilla to coordinate your work upsteam on this.

Let me clarify this: Owen is working with us :) He has taken over the genetic scheduler work I presented at EuroLLVM. One of the bottlenecks we had was the frontend hence the change. I agree that this should have been made clearer (@owenrodley, can you create a bugzilla account and assign the bug to yourself ?)

In https://reviews.llvm.org/D53055#1260195, @andreadb wrote:

>




> The default pipeline in llvm-mca doesn't simulate any hardware frontend logic.
> 
> The `Fetch Stage` in llvm-mca is only responsible for creating instructions and moving them to the next pipeline stage.
>  It doesn't have to be confused with the Fetch logic in the hardware frontend, which - as you wrote - is responsible for fetching portions of a cache line every cycle, and feed them to the decoders via an instruction byte queue.
> 
> The llvm-mca Fetch stage is equivalent to an unbounded queue of already decoded instructions. Instructions from every iteration are immediately available at cycle 0.

All of this sounds more like a naming issue than an issue about what Owen is trying to implement.
Maybe we could rename `FetchState` into `DecodedStage` or something like this ?

> Now that llvm-mca is a library, people can define their own custom pipeline without having to modify the "default pipeline stages".
>  In particular, I don't want to introduce any frontend concepts in the default pipeline of llvm-mca.
>  For now, any frontend simulation should be implemented by stages that are not part of the default pipeline. The default pipeline should only stay focused on simulating the hardware backend logic.

I guess you meant to say: "the default pipeline should only stay focused on simulating what is modeled in the MCSchedModel" ? If we can carve out something that is common to all frontends, then it could end up in MCSchedModel, and then be in the default llvm-mca pipeline. (BTW the resource pointed to by Roman shows that the approach here might not be generic enough).
Until then it feels like the flag is a low-cost approach to implementing this.


Repository:
  rL LLVM

https://reviews.llvm.org/D53055