LLC(1)

πŸ’… LLC(1) β€” the LLVM static compiler, bestie edition

Okay so real talk: this is the manual page for llc, your new fave tool from the LLVM girlies. Pull up a chair, grab a strawberry πŸ“, and let's get into it.


✨ NAME ✨

llc β€” the LLVM static compiler. That's her. That's the whole name. Iconic, brief, no notes.


πŸŽ€ SYNOPSIS πŸŽ€

llc [options] [filename]

Literally that's it. Options go here, file goes there. Slay.


πŸ¦‹ DESCRIPTION πŸ¦‹

So llc takes your LLVM source inputs and compiles them into assembly language for a specific architecture. Then you take that assembly output, run it through a native assembler and linker, and boom β€” you've got yourself a native executable. Main character energy fr fr. πŸ’–

Now, which architecture is it gonna generate assembly for? The choice is automatically determined from the input file β€” unless you use the -march option to override the default. She's smart like that. 🧚


πŸ‘‘ OPTIONS πŸ‘‘

Okay this is the big section, get comfy.

If filename is - or just... omitted entirely, llc reads from standard input. Otherwise it reads from filename. Inputs can be in either the LLVM assembly language format (.ll) or the LLVM bitcode format (.bc). Both are valid, no gatekeeping here. πŸ’…

If the -o option is omitted, then llc sends its output to standard output if the input is from standard input. And if -o specifies -, the output goes to standard output too. Same vibe.

But if there's no -o option specified and an input file other than - is specified, then llc creates the output filename by taking the input filename, removing any existing .bc extension, and adding a .s suffix. Cute little naming convention, honestly.

Other llc options are described below. Buckle up. 🎒

🌸 End-user Options 🌸

  • -help β€” prints a summary of command line options. Your little helper, your little guy.
  • -o <filename> β€” use <filename> as the output filename. See the summary above for more details (you know, the whole .s suffix situation).
  • -O=uint β€” generate code at different optimization levels. These correspond to the -O0, -O1, -O2, and -O3 optimization levels used by clang. Pick your fighter. πŸ”₯
  • -mtriple=<target triple> β€” override the target triple specified in the input file with the specified string. She said "not today, input file." πŸ’€
  • -march=<arch> β€” specify the architecture for which to generate assembly, overriding the target encoded in the input file. Wanna see a list of valid architectures? Peep the output of llc -help. By default this is inferred from the target triple or autodetected to the current architecture.
  • -mcpu=<cpuname> β€” specify a specific chip in the current architecture to generate code for. By default this is inferred from the target triple and autodetected to the current architecture. For a list of available CPUs, use:
llvm-as < /dev/null | llc -march=xyz -mcpu=help
  • -filetype=<output file type> β€” specify what kind of output llc should generated. (Yes, the original says "generated," she's quirky like that.) Your options are:
    • asm β€” for textual assembly ('.s')
    • obj β€” for native object files ('.o')
    • null β€” for not emitting anything (for performance testing)
Heads up bestie: not all targets support all options. Know your target. 🫢
  • -mattr=a1,+a2,-a3,... β€” override or control specific attributes of the target, such as whether SIMD operations are enabled or not. The default set of attributes is set by the current CPU. For a list of available attributes, use:
llvm-as < /dev/null | llc -march=xyz -mattr=help
  • --frame-pointer β€” specify effect of frame pointer elimination optimization (all, non-leaf, none).
  • --disable-excess-fp-precision β€” disable optimizations that may produce excess precision for floating point. ⚠️ Note that this option can dramatically slow down code on some systems (e.g. X86). Worth it sometimes, but know the cost.
  • --enable-no-infs-fp-math β€” enable optimizations that assume no Inf values. Living dangerously, but make it floating point. πŸ’€
  • --enable-no-nans-fp-math β€” enable optimizations that assume no NAN values.
  • --enable-no-signed-zeros-fp-math β€” enable FP math optimizations that assume the sign of 0 is insignificant.
  • --enable-no-trapping-fp-math β€” enable setting the FP exceptions build attribute not to use exceptions.
  • --enable-unsafe-fp-math β€” enable optimizations that make unsafe assumptions about IEEE math (e.g. that addition is associative) or may not work for all input ranges. These optimizations allow the code generator to make use of some instructions which would otherwise not be usable (such as fsin on X86). She said unsafe and she meant it. πŸ™ˆ
  • --stats β€” print statistics recorded by code-generation passes. Numbers! Data! We love her. πŸ“Š
  • --time-passes β€” record the amount of time needed for each pass and print a report to standard error.
  • --load=<dso_path> β€” dynamically load dso_path (a path to a dynamically shared object) that implements an LLVM target. This will permit the target name to be used with the -march option so that code can be generated for that target. Plug in a new target like it's a new accessory. πŸŽ€
  • -meabi=[default|gnu|4|5] β€” specify which EABI version should conform to. Valid EABI versions are gnu, 4 and 5. The default value (default) depends on the triple.
  • -stack-size-section β€” emit the .stack_sizes section which contains stack size metadata. The section contains an array of pairs of function symbol values (pointer size) and stack sizes (unsigned LEB128). The stack size values only include the space allocated in the function prologue. Functions with dynamic stack allocations are not included. Read that twice. πŸ’…
  • -remarks-section β€” emit the __remarks (MachO) section which contains metadata about remark diagnostics.

πŸ’œ Tuning/Configuration Options πŸ’œ

  • --print-after-isel β€” print generated machine code after instruction selection (useful for debugging). Peek behind the curtain. πŸ¦‹
  • --regalloc=<allocator> β€” specify the register allocator to use. Valid register allocators are:
    • basic β€” basic register allocator.
    • fast β€” fast register allocator. It is the default for unoptimized code.
    • greedy β€” greedy register allocator. It is the default for optimized code.
    • pbqp β€” register allocator based on 'Partitioned Boolean Quadratic Programming'. Say that five times fast, I dare you. 😭
  • --spiller=<spiller> β€” specify the spiller to use for register allocators that support it. Currently this option is used only by the linear scan register allocator. The default spiller is local. Valid spillers are:
    • simple β€” simple spiller
    • local β€” local spiller

⭐ Intel IA-32-specific Options ⭐

  • --x86-asm-syntax=[att|intel] β€” specify whether to emit assembly code in AT&T syntax (the default) or Intel syntax. Pick your dialect, bestie. πŸŽ€

πŸ”₯ EXIT STATUS πŸ”₯

If llc succeeds, it will exit with 0. Otherwise, if an error occurs, it will exit with a non-zero value. That's the vibe check right there β€” 0 means she ate, anything else means something went sideways. πŸ’€


🌈 SEE ALSO 🌈

  • lli(1) <lli.html> β€” her bestie, go say hi.

🌸 Author 🌸

Maintained by the LLVM Team (https://llvm.org/). Kings and queens, all of them. πŸ‘‘


2003-2026, LLVM Project. All the rights, reserved and cozy.


🫢 That's the whole page, no cap. Go compile something gorgeous.

LLVM Β· version 15 Β· dated 2026-09-09 Β· this manual page is literally called LLC(1) and she's perfect πŸ’–βœ¨

πŸ“¦ where this page comes from