CLI Flag Inventory

cicc v13.0 accepts approximately 111 unique flag keys across five parsing sites, expanding to ~142 flag+value combinations when counting value variants, and ~169 when including all architecture triplets. Flags are parsed in sub_8F9C90 (real main), sub_900130 (LibNVVM path A), sub_12CC750/sub_9624D0 (LibNVVM option processors), and sub_12C8DD0 (flag catalog builder with 65 registered configurations).

The flag system is architecturally split into two layers: a hardcoded dispatch layer in the top-level parsers (sub_8F9C90, sub_900130, sub_12CC750/sub_9624D0) that handles mode selection, pass-through, LTO, and structural flags via strcmp/prefix-match chains; and a BST-backed catalog layer (sub_12C8DD0 + sub_95EB40/sub_12C8B40) that handles all flags whose effect is purely "store a value and forward strings to output vectors."

The Four Output Vectors

Every flag ultimately routes its effects into one or more of four output std::vector<std::string> buffers. These vectors are the sole interface between the CLI parser and the downstream pipeline stages:

Each vector element is a 32-byte std::string with SSO. At function exit (lines ~1462-1553 of sub_9624D0), each vector is serialized: count = (end - begin) >> 5, then malloc(8 * count) for the char** array, with each string individually malloc(len+1) + memcpy + null-terminated.

The lto vector receives no seed string and is only populated by explicit LTO flags (-Xlto, -olto, -gen-lto, -link-lto, --device-c, --force-device-c, host-ref flags) and the architecture string.

Mode Selection

The top-level entry point sub_8F9C90 sets a mode variable v263 that selects the compilation pipeline:

Within the LibNVVM option processors (sub_12CC750/sub_9624D0), the first argument is checked as a 4-byte or 8-byte integer for phase routing. Phase routing is stored at a1+240:

When phase routing is active (a1+240 != 0), sub_95C880(phase_id, argc, argv, &count, &mode_flags) returns the allocated argv array for that single phase, stored directly into the corresponding output pair. When a1+240 == 0, mode flags default to 7 (all phases), and the full multi-phase option parsing loop runs.

The BST-Backed Flag Catalog

Catalog construction: sub_95EB40 / sub_12C8DD0

The function sub_95EB40(a1, cl_mode_flag) (standalone path) or sub_12C8DD0 (LibNVVM path) builds a std::map<std::string, OptionEntry> at a1+248. The underlying data structure is a C++ red-black tree (the standard library std::map implementation), with the tree root at a1+248, the sentinel/end node at a1+256, and the node count at a1+288.

Registration is performed by 65 calls to sub_95E8B0 + sub_95BF90 (standalone) or sub_12C8B40 (LibNVVM). Each call inserts one BST node.

BST node layout (168 bytes)

Each node in the red-black tree has the following layout:

BST lookup: sub_95D600 / sub_12C8530

When the main parsing loop encounters a flag string, it calls sub_95D600 (standalone) or sub_12C8530 (LibNVVM) to perform a standard std::map::lower_bound-style traversal of the red-black tree. The lookup compares the input flag string against registered key strings at node offset +32 using strcmp semantics. On match, the node's three forwarding strings (lnk/opt/llc) are split on spaces and appended to their respective output vectors.

Duplicate detection

Each BST node's value pointer points into the options structure. If the value storage already has a non-zero sentinel (the QWORD immediately following the 32-byte STR32 slot), the flag was already set. On duplicate:

"libnvvm : error: <flag> defined more than once"

Flags NOT in the catalog

The following flag categories are handled by hardcoded strcmp/prefix-match chains in the main parsing loop BEFORE the catalog lookup, and therefore bypass the BST entirely:

• Mode selection flags (-lnk, -opt, -llc, -nvc, -libnvvm)
• -Ofast-compile=<level> (parsed at lines ~690-833)
• Pass-through flags (-Xopt, -Xllc, -Xlnk, -Xlto)
• LTO flags (-lto, -gen-lto, -gen-lto-and-llc, -link-lto, -olto, -gen-opt-lto, --trace-lto)
• Device compilation flags (--device-c, --force-device-c, --partial-link)
• Host reference flags (-host-ref-{ec,eg,ek,ic,ig,ik})
• -maxreg=<N> (has its own duplicate-check logic at a1+1200)
• -split-compile=<N>, -split-compile-extended=<N> (at a1+1480/a1+1488)
• -opt-passes=<pipeline> (at a1+1512/a1+1520)
• -discard-value-names=<0|1> (complex multi-phase interaction)
• -time-passes (must be sole flag; unsupported in LibNVVM API path)
• -cl-mode (sets v278=1, affects routing for -prec-div, -fast-math, -prec-sqrt)
• -jump-table-density=<N> (forwarded directly to llc)
• -jobserver (forwarded to opt)
• --emit-optix-ir (disables ip-msp + licm, sets a13=0x43)
• --nvvm-64, --nvvm-32 (handled in sub_95C230)

If none of the hardcoded checks match and the BST lookup also fails, the flag falls through to the catchall entry at options structure offset +1256, which triggers:

"libnvvm : error: <flag> is an unsupported option"

Complete Flag-to-Pipeline Vector Routing Table

The table below documents every flag's routing from user input to the four output vectors. "Store" indicates the options structure offset where the value is recorded. Flags marked with [BST] are registered in the catalog; flags marked with [HC] are hardcoded in the parsing loop.

Architecture Flags [BST]

All 24 architecture entries share options structure offset +552 and follow the same 3-column pattern:

Note: the a and f sub-variants share the base SM number for __CUDA_ARCH (e.g., sm_100a and sm_100f both emit __CUDA_ARCH=1000) but get distinct -opt-arch= and -mcpu= strings. The architecture string is also stored into the lto vector via sub_95D700, preserving the full -arch=compute_XX string.

Architecture validation bitmask

Architecture is validated at a1+8 using bitmask 0x60081200F821:

offset = SM_number - 75
if (offset > 0x2E || !_bittest64(&0x60081200F821, offset))
    -> ERROR: "is an unsupported option"

Valid bit positions:

Maximum offset: 0x2E = 46 (SM 121). All pre-Turing architectures (SM 70 and below) are rejected.

Architecture specification forms

Architecture can be specified in many forms, all converging to a numeric SM value. Trailing a or f suffixes are stripped before numeric parsing. On parse failure: "Unparseable architecture: <val>".

Hex-encoded flag checks in sub_8F9C90:

• 0x6D733D7570636D2D = -mcpu=sm
• 0x6372612D74706F2D = -opt-arc
• 0x6F633D686372612D = -arch=co
• 0x6372615F766E2D2D = --nv_arc

Optimization Level Flags

The -opt=<N> flags do not directly emit to any vector at registration time. Instead, at the routing stage (lines 1444-1563 of sub_9624D0), the optimization level drives one of three code paths:

1. Custom pipeline set (a1+1520 != 0): emits -passes=<pipeline_string> to opt vector
2. Normal mode (a1+1520 == 0, a1+1640 == 0): emits -O<level> to opt vector
3. Fast-compile mode (a1+1640 != 0): emits -optO<level> + -llcO2 to llc vector

Floating Point Control Flags

Note on -prec-div: the CUDA vs CL distinction is controlled by the magic cookie a4 (0xABBA = CUDA, 0xDEED = OpenCL). CUDA -prec-div=1 maps to -nvptx-prec-divf32=2 (IEEE-correct division), while CL maps to level 1 (software approximation). When -prec-div=0 is set under CUDA, it still maps to -nvptx-prec-divf32=1 (not 0), because CUDA never drops below software approximation.

Fast Math Aggregate Flags

-unsafe-math always sets FTZ in the backend (-nvptx-f32ftz), while CUDA -fast-math does not touch the backend FTZ flag -- it only sets the preprocessor define and the optimizer flag.

Debug and Diagnostic Flags

Inlining and Function Flags

Optimization Control Flags

These three are emitted by -disable-allopts (see above); they do not exist as independent user flags.

Rematerialization Flags

These are multi-flag compound emissions. Note the subtle difference: -disable-nvvm-remat sets -nv-disable-remat=true (disables classic remat) but -enable-new-nvvm-remat=false (also disables new remat), while -disable-new-nvvm-remat disables both new remat AND classic remat AND register-pressure-aware MCSE.

Analysis and Transform Control Flags

Note: disable-load-select-transform is registered WITHOUT a leading - in the catalog.

Pass-Through (Forwarding) Flags [HC]

Each consumes the next argument from argv.

LTO Flags [HC]

Device Compilation Flags [HC]

Host Reference Flags [HC]

Pipeline Control Flags [HC]

Ofast-compile Levels [HC]

Stored at a1+1640. Only ONE -Ofast-compile= is allowed; a second triggers "libnvvm : error: -Ofast-compile specified more than once".

When -Ofast-compile is active (level >= 1), the -passes=/-O routing is bypassed. Instead: -optO<level> and -llcO2 are emitted to the llc vector (lines 1453-1460).

Miscellaneous Flags [HC]

Discard-Value-Names [HC]

This flag has the most complex interaction logic in the parser. Seven boolean tracking variables control its behavior:

When a4 == 0xABBA (CUDA) and no explicit -discard-value-names:

• Default: discard (a1+232 = 1)
• Emits: -lnk-discard-value-names=1 to lnk, -opt-discard-value-names=1 to opt, -lto-discard-value-names=1 to lto
• UNLESS overridden by per-phase -X flags

When a4 == 0xDEED (OpenCL): only applies if (a13 & 0x20) is set.

Error on conflicting definitions: "libnvvm : error: -discard-value-names defined more than once, or defined for both libnvvm and sub-phase".

I/O and General Flags

Recognized input extensions: .bc, .ci, .i, .cup, .optixir, .ii. The .cup extension triggers --orig_src_path_name / --orig_src_file_name handling.

Options Structure Layout

The options structure passed as a1 to sub_9624D0/sub_12CC750 is ~1,644 bytes. Key offsets:

Each STR32 is a 32-byte std::string with SSO (small string optimization). The QWORD "already-set sentinel" fields serve as duplicate-detection guards.

Compilation Mode Bitmask (a13)

The a13 parameter is an in/out bitmask that controls which pipeline phases execute and what LTO mode is active:

Magic Cookie Values (a4)

Default Values When Flags Are Absent

When a registered flag is not found in the user's arguments, sub_9624D0 checks whether the stored-value sentinel is zero and applies defaults:

Differences Between sub_12CC750 and sub_9624D0

The two option processors are near-identical. Key differences:

Error Handling

All error strings follow the pattern "libnvvm : error: <message>":

Function Address Map

Cross-References

• Optimization Levels -- O-level pipeline builders and fast-compile tiers
• Configuration Knobs -- 1,496 cl::opt knobs set by the flags documented here
• NVVMPassOptions -- 222-slot struct that receives CLI-routed values
• Environment Variables -- environment-based configuration (parallel to CLI)
• Pipeline Overview -- how the four output vectors feed into pipeline stages
• nvcc Interface -- how nvcc constructs the argv passed to cicc
• Architecture Targets -- SM feature gating driven by -arch=compute_<N>