Determining whether it is safe to hoist a load instruction out of control flow
depends on complex hardware and driver details. Rather than encoding this as
knobs in every NIR pass that wants to do so (notably nir_opt_preamble and
nir_opt_peephole_select), add a per-load ACCESS flag for backends to set.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24011>
{ ACCESS_NON_WRITEABLE, "readonly" },
{ ACCESS_NON_READABLE, "writeonly" },
{ ACCESS_CAN_REORDER, "reorderable" },
+ { ACCESS_CAN_SPECULATE, "speculatable" },
{ ACCESS_NON_TEMPORAL, "non-temporal" },
{ ACCESS_INCLUDE_HELPERS, "include-helpers" },
};
* from fragment mask buffer.
*/
ACCESS_FMASK_LOWERED_AMD = (1 << 11),
+
+ /**
+ * Whether it is safe to speculatively execute this load. This allows
+ * hoisting loads out of conditional control flow (including out of software
+ * bounds checks). Setting this optimally depends on knowledge of the
+ * hardware. Speculation is safe if out-of-bounds access does not trigger
+ * undefined behaviour (even though the returned value of the speculated load
+ * is bogus). This is the case if there is hardware-level bounds checking, or
+ * if MMU faults are suppressed for the load.
+ */
+ ACCESS_CAN_SPECULATE = (1 << 12),
};
/**