Environment Variable and Runtime Gate Catalog

tileiras consumes external configuration through two distinct mechanisms. The first is the libc getenv(3) family, reachable via the PLT stub at 0x004055B0 and through the wrapper sub_45AE9A0 (getenv-into- std::string). The second is a band of process-wide scalar globals in the 0x5B6xxxx region of .bss/.data -- the "runtime gates" -- whose default values are written by C++ static constructors during dynamic-linker init, bound by name to LLVM cl::opt storage, then read directly by optimizer passes. Both mechanisms wire up during program startup: env vars are pulled lazily on first consumer use (or at ctor time for a couple of LLVM-Support strings), while gates populate unconditionally before main runs and then optionally get overwritten by --<flag> command-line arguments parsed through the LLVM CommandLine library. Together they form the entire externally-tunable surface of tileiras -- no config file, no JSON, no INI, just env vars plus cl::opt flags backed by these scalar globals.

Table 1: Environment Variables

Columns: env var name | consumer sub_ADDR | behavior | default when unset.

Two other getenv-touching helpers exist but stay dormant: one for command-line-option scanning (sub_4535E90 -- llvm::cl::ParseCommandLineOptions's EnvVar arg, dormant because main passes null) and one for response-file expansion (sub_45AEBB0). They are listed for completeness; in production runs of tileiras they read no environment variables.

Table 2: Runtime Gates

Columns: address (byte_* / qword_*) | populating ctor | default value | consumer pass / routine. Width is 1 byte for byte_*, 4 bytes for the low-DWORD of a qword_* integer slot. Numeric cl::opt<int> slots are laid out as [qword_X] (Initial) + [qword_X+0x10] (Default) plus a BYTE4(qword_X+0x10)=1 "has-default" flag; consumers always read the Initial via LODWORD.

The consumer-side read of any cl::opt<int> gate is a literal mov from the Initial slot, equivalent to:

/* every pass that consults a numeric gate compiles to this shape; the
 * address is baked in by static-init linkage, so the call site is one
 * load and no indirection. */
static inline int32_t read_gate_int(const void *initial_slot) {
    return *(const int32_t *)initial_slot;
}

/* boolean gates use a 1-byte slot; nonzero means enabled. */
static inline bool read_gate_bool(const uint8_t *byte_slot) {
    return *byte_slot != 0;
}

Honouring the same --flag surface in a reimplementation only requires wiring each per-option storage cell to a cl::opt<T> so ParseCommandLineOptions can overwrite it; everything downstream is a direct read.

A second class of gates is .bss-resident with no static writer: they default to zero and flip the first time their runtime consumer touches them, behaving as a one-shot latch. They never appear in --help because they are never bound to cl::opt storage -- pure runtime state. Examples: byte_5B6AF80 (scev-cgp-check-latency cache, written by sub_27F7D20), byte_5B6B4C0 (BASR pre-filter predicate, written by sub_2800C10), dword_5B6B7C0 and dword_5B6B940 (SCEV-CGP runtime counters), and byte_5B6D260 (MSPO cfg-selector switch set on first call to sub_2862FD0).

How env vars get propagated to passes

The lifecycle is split across three phases. Phase 1 (ctor time): at dynamic-linker init the C++ static constructors ctor_3xx run and write default values into the 0x5B6xxxx band, simultaneously calling sub_4534CC0(..., "<name>", <len>) to register each gate's textual flag name with LLVM's CommandLine global registry. A few env vars are pulled this early too -- LLVM_OVERRIDE_PRODUCER in ctor_611 lands in qword_5BDF538 before main ever runs, so changing it post-launch has no effect. Phase 2 (main startup): the driver invokes llvm::cl::ParseCommandLineOptions, which walks argv and overwrites any gate whose --<name> flag appears, leaving all others at their ctor-installed defaults. The driver then calls sub_5773C0 to populate its toolkit-root std::string from CUDA_ROOT / CUDA_HOME / CUDA_PATH (or /proc/self/exe), and sub_1A41D30 does the same for NVVM later when libnvvm is asked to locate libdevice. Phase 3 (per-pass / per-kernel): consumer passes read the gates directly through the global addresses cached at compile time -- there is no getOption() indirection at the call site, the compiler emitted a literal mov from 0x5B6xxxx. The TILEIR-prefixed env vars are an exception to this static ladder: each is fetched on first use inside its consumer (sub_7B6970, sub_7A9D60, sub_8D9DD0, sub_12C8DF0), bypassing the gate band entirely because they were never registered with CommandLine. The result is two parallel surfaces -- the cl::opt-backed gates that respond to both --flag and (for a handful) env vars, and the standalone TILEIR / TILE_AS env vars that have no --flag equivalent and are reachable only by setting the variable.

Cross-References

Performance and Cost Model lists the subset of these tunables that shift cost-model behaviour at compile and runtime, including the SMEM ceiling, the TMA-preferred layout bias, and the warp-specialisation threshold.