This is the mail archive of the
mailing list for the GCC project.
Re: Combined top-down and bottom-up instruction scheduler
- From: Jeff Law <law at redhat dot com>
- To: Evandro Menezes <e dot menezes at samsung dot com>, "'Vladimir Makarov'" <vmakarov at redhat dot com>, "'Aditya K'" <hiraditya at msn dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 8 Sep 2015 15:28:11 -0600
- Subject: Re: Combined top-down and bottom-up instruction scheduler
- Authentication-results: sourceware.org; auth=none
- References: <BLU179-W6188AF5C5B442B4282F2F0B6530 at phx dot gbl> <55EF2E2C dot 4000601 at redhat dot com> <55EF39A9 dot 5060002 at redhat dot com> <55EF4738 dot 7020906 at redhat dot com> <02c201d0ea7b$05aff900$110feb00$ at samsung dot com>
On 09/08/2015 03:12 PM, Evandro Menezes wrote:
Which is why I mentioned optimizing for throughput at the retirement
stage rather than traditional latency scheduling.
cache miss and transcendental functions). You might also attack
issues like throughput at the retirement stage for example.
Our motivation stems from the fact that even modern, aggressively OOO
processors don't have orthogonal resources. Some insns depend on expensive
circuitry (area or power wise) that is added only once, making such insns
simply scalar, though most of other insns enjoy multiple resources capable
of executing them as superscalar. That's why we believe that a hybrid
approach might yield good results. We don't have data, for it possibly
requires implementing it first.
I'd also argue that looking at an OOO pipeline in a steady state is not the
only approach. It's also important to consider how quickly the pipeline can
be replenished or warmed up to reach a steady state.
That's from a real world case -- the PA8000 where retirement bandwidth
was at a premium (relative to functional unit bandwidth).