[AMDGPU] Add block carried latency to CoExecSched (#192324)
This adds some rudimentary logic to check for load dependencies across
blocks. Since the scheduling algorithm is local scheduling per region,
we do not have about latencies carried from other blocks. Rather than
constructing a global DAG to accurately measure these latencies, this PR
uses a heuristic to estimate the incoming latency.
We limit our incoming dependencies to load instructions, as these are
expected to be the ones that cause problems. This uses the full latency
of the instruction as the incoming latency to cover. We check for any
use that occurred later in the def block - if we find such a use then we
do not have incoming latency as we have already waited for the load.
Using the incoming latency assumes that the load is the last instruction
in the block, and that the branch takes 0 cycles. Aside from not fully
understanding the dependencies of other blocks, a challenge in defining
a more accurate incoming latency is that it is possible that the block
with the load may be rescheduled.
[2 lines not shown]
[CMake] Clean up factored lit dependency names
Replace the opaque SHA1-based stamp and anchor names with readable names
based on the lit project. Document why the symbolic outputs and internal
anchor target are needed.
Warn once when the active project minimum reaches CMake 3.27, making the
compatibility fallback obsolete.
Prevent the vendored fmt headers from being shadowed by devel/fmt.
this _should_ fix errors tb@ is seeing when building x11/gnome/gjs and dpb
junks fmt.
[lldb] Report a scripted frame's variables with the frame's value type (#221708)
A scripted frame's variable exists as two objects: a Variable holding
the scope the frame assigned it, and a ValueObject holding what the
frame built. SBValue::GetValueType() reports the ValueObject's, and
GetValueObjectForFrameVariable handed that ValueObject back unchanged,
so the scope never reached a client. A ValueObject built in Python is a
ValueObjectConstResult, which reports how it was produced rather than
which variable it stands for, leaving anything that groups a frame's
variables by scope unable to place it. `frame variable` was unaffected
because it reads the Variables directly.
This patch presents the ValueObject under that scope instead. A class
for this already existed as ValueObjectRecognizerSynthesizedValue, which
frame recognizers use to name an argument: both take a ValueObject that
cannot report the ValueType it is being presented as and supply that
ValueType for it, so generalize that one into
ValueObjectSynthesizedValue and use it for both. ValueObjectVariable is
the other class that pairs a ValueObject with a ValueType, but it cannot
[28 lines not shown]
Address comments.
Avoid prioritizing DMA and fence candidates while they still have an effective stall.
Make the top-down requirement explicit and remove unreachable bottom-up handling.
