Sorry, still haven't found time to look at the patch properly (hopefully after stage 1 closes, if not before), but:
Jeff Law <jeffreya...@gmail.com> writes: > [...] > On 10/31/24 1:35 PM, Vineet Gupta wrote: >>> And if it doesn't strictly need to be a valid schedule are we giving an >>> overly-optimistic view of the best that can be done from a pressure >>> standpoint with this change? And if so, is that wise? >> >> As I mentioned above, the design goal of model schedule is to keep pressure >> to min. >> So indeed we might be a bit more optimistic than reality here. But main list >> scheduler fixes >> that if that leads to undesired outcomes. What we are trying to do here is >> not pessimize >> in certain cases, especially when that's not by design but just an outcome >> of the >> implementation subtlety. > And my point is that if I'm allowed to generate a minimal register > pressure schedule without needing it to generate the same semantics as > the original code, then I could drastically reduce the register pressure > :-) But I'd also claim that doing so isn't actually useful. > > The mental model I'd work from is we want to know the minimal pressure > while still preserving the original code semantics -- unless someone who > knows this better (ie Richard S) were to say otherwise. Yeah, that's right. The "model" schedule was supposed to be a correct schedule that completely ignored the target pipeline and instead tried to minimise register pressure. This was in contrast to the list scheduler without any pressure heuristics, which tried to fill pipeline bubbles while completely ignoring register pressure. The idea was then to strike a balance between the list scheduler's natural tendency to do things as soon as the pipeline model allowed vs the model scheduler's tendency to delay things that would increase pressure. But all three schedules (the two extremes, and the compromise) are intended to be correct in isolation. Richard
