Embedded ptxas Options

nvlink v13.0.88 embeds a complete copy of the ptxas assembler/compiler backend. When that backend is invoked (for LTO compilation, PTX JIT, or Mercury finalization), it accepts its own independent set of command-line options separate from nvlink's own CLI flags. Two functions define this option set: sub_1103030 builds the option definition table (long/short names, types, defaults, help text), and sub_1104950 parses argv against that table and populates a compiler-state structure at known offsets.

How Options Reach the Embedded ptxas

The embedded ptxas backend never reads directly from the user's command line. Options flow through two paths:

1. -Xptxas passthrough. nvlink's own CLI parser (sub_427AE0) accumulates -Xptxas values into a linked list at qword_2A5F238. The LTO pipeline's sub_429BA0 serializes this list into a space-separated string that becomes part of the argv vector passed to the embedded ptxas entry point.

2. Programmatic forwarding. sub_429BA0 also appends options derived from nvlink's own state: -arch=sm_N from the target architecture, -maxreg=N from --maxrregcount, -Ofast-compile=LEVEL, -g from --debug, -generate-line-info, and several others. See Option Forwarding to cicc for the complete forwarding logic.

The combined argv vector is passed to sub_1104950, which calls sub_1103030 to build the option table, then parses the vector using the shared sub_42E5A0 parser. Parsed values are extracted with sub_42E390 into a compiler-state structure (base pointer a3), where each option writes to a specific byte offset.

Option Definition Table (sub_1103030)

sub_1103030 creates a fresh option parser instance via sub_42DFE0(0) and registers all options via sub_42F130. Each sub_42F130 call passes:

sub_42F130(parser, long_name, short_name, type, multiplicity, flags, context,
           allowed_keywords, reserved, default_value, reserved2,
           value_placeholder, help_text)

Option types: 0 = file-list, 1 = bool, 2 = string, 4 = integer, 5 = int64, 7 = special. Multiplicity: 0 = flag-only (bool), 1 = single value, 2 = multi-value (accumulates), 3 = multi-value with keyword validation.

After registering all options, sub_1103030 invokes sub_42E5A0 to parse the passed argc/argv against the table, then checks for --trap-into-debugger (calls sub_42FA60 to install signal handlers), --tool-name (updates the internal program name), --help (prints help and exits), and --version (prints version banner and exits). The version banner reads:

ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Aug_20_01:55:12_PM_PDT_2025
Cuda compilation tools, release 13.0, V13.0.88
Build cuda_13.0.r13.0/compiler.36424714_0

Complete Option Catalog

The following catalog lists every option registered by sub_1103030, in registration order. The "State Offset" column shows where sub_1104950 stores the parsed value within the compiler-state structure (base pointer a3). The "Size" column indicates the sub_42E390 copy size.

Debug and Diagnostic Options

Optimization Options

Register and Launch Configuration

Compilation Mode Options

Target Architecture

Cache Policy Options

Cache string values are converted to integer codes by sub_1102260. Specifying both force-load-cache and def-load-cache simultaneously is an error -- force takes precedence and def is zeroed. Same for the store pair.

Warning and Diagnostic Options

Profiling and Statistics

Code Generation Options

Synchronization and Warp Options

Sanitizer Options

Concurrency Options

PTX Input Options

Output Options

Video and Memory Options

CUDA API Options

Workaround Flags (Bug-Fix Switches)

These are numbered software-workaround flags corresponding to internal NVIDIA bug IDs. They allow targeted behavior changes without modifying the broader optimization pipeline.

Utility Options

Option Extraction and Validation (sub_1104950)

After sub_1103030 parses the argv, sub_1104950 calls sub_42E390 for each option to copy the parsed value into the compiler-state structure at a3. The extraction follows a strict order and includes validation logic:

Dependency Validation

sub_1104950 enforces mutual exclusion and dependency rules between options. These checks use sub_42E580 (was-specified) to distinguish "explicitly set" from "has default value":

Ofast-Compile Interaction

The Ofast-compile level has cascading effects on other options. sub_1104950 validates the level string (max, mid, min, 0) and enforces:

maxrregcount Resolution

The maxrregcount value goes through a multi-step resolution in sub_1104950:

1. If the string is "archmax", use *(arch_profile + 96) -- the architecture's maximum register count.
2. If the string is "archmin", use *(arch_profile + 100) -- the architecture's minimum register count.
3. Otherwise, parse as integer via strtoll.
4. If --compile-as-tools-patch is active and the value exceeds the tools-patch minimum (8 * (SM >= 17) + 16), clamp and warn.
5. If the integer exceeds the architecture maximum, clamp to *(arch_profile + 96) and warn.
6. If the integer is below the ABI minimum for the profile, bump up and warn.
7. Store the final value at a3+136.

The same resolution applies to device-function-maxrregcount, stored at a3+140.

SM Version Derivation

sub_1104950 calls sub_15C3DD0 to convert the gpu-name string (e.g. "sm_90") to an internal numeric version (v23). This integer is used throughout for architecture-gated validation:

The family lookup table at dword_1EED2E0 maps (v23 - 7) to an architecture family code (e.g. 100 for Blackwell). This family code gates sw4915215 (only family 100) and disable-smem-reservation behavior.

Compiler-State Structure Layout

The compiler-state structure populated by sub_1104950 is at least 680 bytes, accessed through base pointer a3. Key regions:

Interaction with the Compilation Driver

sub_1112F30 (the main compilation driver) reads options from the compiler-state structure populated by sub_1104950. Key interactions:

• Cache policies at offsets 304-316 configure the codegen's default and forced load/store cache modifiers. These flow into sub_110AA30 (per-function codegen init) which reads them to set up instruction-level cache annotations.
• compile-as-tools-patch (offset 343) triggers a special mode where textures, surfaces, samplers, and constants are handled differently. maxrregcount is clamped to ABI minimum.
• position-independent-code (offset 606) enables PIC code generation. The driver reads this along with compile-only (342) and extensible-whole-program (505) to determine the compilation model.
• device-debug (offset 288) causes sub_1102070 to be called, which configures debug-mode codegen. When device-debug is set, verbose-tkinfo is auto-enabled.
• opt-level 0 at offset 148 forces sp-bounds-check on and sw2614554 off, overriding explicit settings.
• split-compile (offset 284) configures the thread pool created by sub_464AE0 for concurrent per-function compilation.

Feature Flag Mapping (sub_1100E50)

After option parsing, sub_1100E50 translates selected options into a feature-flag bitfield consumed by the codegen backend. It reads the SM version and option bytes from the compiler-state structure, then calls sub_16E3AA0(feature_table, feature_id, bool_value) for approximately 30 feature flags:

Feature names are retrieved through sub_12B5EF0 and stored as "true"/"false" key-value pairs via sub_448E70 for diagnostic purposes.

Cross-References

• CLI Option Parsing -- nvlink's own option parser, which accumulates -Xptxas values
• Option Forwarding to cicc -- how nvlink builds the ptxas argv from its own state
• Embedded ptxas: Architecture Overview -- the full embedded ptxas address map
• Architecture Dispatch -- SM version dispatch and architecture profiles
• Register Allocation -- how maxrregcount affects the register allocator

Confidence Assessment

Aspect-Level Confidence

Per-Option Verification

Each row below records a direct sub_42F130(..., "<long-name>", ...) call in decompiled/sub_1103030_0x1103030.c. The "Evidence" column identifies where the long-name string lives in nvlink_strings.json or, when the name only appears as a fragment of a longer help/format string, indicates substring. Three options (uumn, cimm, slr) are direct literals in the decompiler output but have no visible standalone entry in the string-table dump -- the backing storage is deduped/overlapped in .rodata but the C-string MUST exist to satisfy the call. All 108 options are additionally verified via their extraction sites in sub_1104950 (sub_42E390 calls writing to a3+N). The "Shared" column marks options that also appear in the ptxas CLI Options page (the standalone ptxas tool), indicating the option surface is shared between the embedded and standalone ptxas binaries.

Summary: 108 options enumerated. 105/108 have direct string evidence in nvlink_strings.json (either exact or embedded as substring in a longer help/format string). 3/108 (uumn, cimm, slr) appear only as direct string literals in the decompiled sub_1103030 calls -- these are short 3-4 character names whose storage is deduped or tail-overlapped with longer strings, invisible to a naive standalone-string dumper but provably present at the call site. 97/108 options (90%) are shared with the standalone ptxas tool documented in the ptxas CLI Options page, confirming that the embedded ptxas in nvlink is substantially the same option-parsing codebase as the separate binary. The nvlink-only options (key, okey, ptx-length, input-as-string -- wait, these ARE shared; the true nvlink-only set is: uumn, cimm, fastimul, slr, reserve-null-pointer, debug-info, nv-host, noFwdPrg, cuda32f3056bbb) are either obsolete debugging flags or NVIDIA-internal undocumented behavior switches.