LLC(1)

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

okay so real quick, the manual name is llc, it lives in the LLVM section 1 manuals, and honestly? she's iconic. let's get into it.


🌸 NAME 🌸

llc β€” the LLVM static compiler. that's it, that's the name, she's not complicated.


πŸ¦‹ SYNOPSIS πŸ¦‹

llc [options] [filename]

like… options, maybe a filename, we move.


✨ DESCRIPTION ✨

so the way that llc works is it takes LLVM source inputs and compiles them into assembly language for a specific architecture. then you can 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.

now, which architecture does it pick for the output assembly? it automatically figures that out from your input file, unless you use the -march option to override the default. so if you don't say anything, she reads the vibes of your file and goes with it. iykyk.


πŸ’– OPTIONS πŸ’–

okay bestie, ground rules first:

if filename is - or you just… don't give one, llc reads from standard input. otherwise it reads from filename. and your inputs can be either the LLVM assembly language format (.ll) or the LLVM bitcode format (.bc). both slay.

if you leave out the -o option, then llc sends its output to standard output β€” but only if the input is coming from standard input. and if -o is set to "-", then the output also goes to standard output. consistency queen.

if there's no -o option and your input file is something other than "-", then llc makes the output filename for you: take the input filename, strip any existing .bc extension, and slap a .s suffix on it. πŸŽ€

and the other options? described below, babes.


πŸ‘‘ End-user Options πŸ‘‘

  • -help β€” prints a summary of the command line options. your lil cheat sheet.
  • -o <filename> β€” use <filename> as the output filename. peep the summary above for more deets.
  • -O=uint β€” generates code at different optimization levels. these line up with the -O0, -O1, -O2, and -O3 optimization levels that clang uses.
  • -mtriple=<target triple> β€” overrides the target triple that's specified in the input file with the string you give it. take that, input file.
  • -march=<arch> β€” specifies the architecture to generate assembly for, overriding the target encoded in the input file. for a list of valid architectures, go look at the output of llc -help. by default this gets inferred from the target triple, or autodetected to the current architecture. no cap.
  • -mcpu=<cpuname> β€” specifies a specific chip in the current architecture to generate code for. by default it's inferred from the target triple and autodetected to the current architecture. want the list of available CPUs? run this:
llvm-as < /dev/null | llc -march=xyz -mcpu=help
  • -filetype=<output file type> β€” specifies what kind of output llc should generate. the options are: asm for textual assembly ('.s'), obj for native object files ('.o'), and null for not emitting anything at all (which is for performance testing). also, heads up: not all targets support all options.
  • -mattr=a1,+a2,-a3,... β€” overrides or controls specific attributes of the target, like whether SIMD operations are enabled or not. the default set of attributes is set by the current CPU. for a list of available attributes:
llvm-as < /dev/null | llc -march=xyz -mattr=help
  • --frame-pointer β€” specifies the effect of the frame pointer elimination optimization. your choices are all, non-leaf, and none.
  • --disable-excess-fp-precision β€” disables optimizations that may produce excess precision for floating point. but ngl, this option can dramatically slow down code on some systems (e.g. X86). so like, know what you're doing πŸ’€
  • --enable-no-infs-fp-math β€” enables optimizations that assume there are no Inf values.
  • --enable-no-nans-fp-math β€” enables optimizations that assume there are no NAN values.
  • --enable-no-signed-zeros-fp-math β€” enables FP math optimizations that assume the sign of 0 is insignificant. zero is zero, ok??
  • --enable-no-trapping-fp-math β€” enables setting the FP exceptions build attribute to not use exceptions.
  • --enable-unsafe-fp-math β€” enables optimizations that make unsafe assumptions about IEEE math (e.g. that addition is associative) or that may not work for all input ranges. these optimizations let the code generator use some instructions that would otherwise be unusable (like fsin on X86). powerful but spicy 🌢️
  • --stats β€” prints statistics recorded by code-generation passes. numbers go brrr.
  • --time-passes β€” records how much time each pass needs and prints a report to standard error. clocking the girlies in.
  • --load=<dso_path> β€” dynamically loads dso_path (a path to a dynamically shared object) that implements an LLVM target. this lets that target name be used with the -march option so code can be generated for it. plug it in, plug it in πŸ”Œ
  • -meabi=[default|gnu|4|5] β€” specifies which EABI version to conform to. valid EABI versions are gnu, 4, and 5. the default value (default) depends on the triple.
  • -stack-size-section β€” emits 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. sorry bestie.
  • -remarks-section β€” emits the __remarks (MachO) section, which contains metadata about remark diagnostics.

πŸŽ€ Tuning/Configuration Options πŸŽ€

  • --print-after-isel β€” prints the generated machine code after instruction selection. super useful for debugging 🫢
  • --regalloc=<allocator> β€” specifies which register allocator to use. the valid register allocators are:
    • basic β€” the basic register allocator.
    • fast β€” the fast register allocator. this one is the default for unoptimized code.
    • greedy β€” the greedy register allocator. this one is the default for optimized code.
    • pbqp β€” a register allocator based on 'Partitioned Boolean Quadratic Programming'. yeah. that's the whole name.
  • --spiller=<spiller> β€” specifies the spiller to use for register allocators that support it. currently this option is only used by the linear scan register allocator. the default spiller is local. the valid spillers are:
    • simple β€” simple spiller
    • local β€” local spiller

🌈 Intel IA-32-specific Options 🌈

  • --x86-asm-syntax=[att|intel] β€” specifies whether to emit assembly code in AT&T syntax (that's the default, bestie) or Intel syntax. choose your fighter.

πŸ’€ EXIT STATUS πŸ’€

if llc succeeds, she exits with 0 πŸŽ‰. otherwise, if an error happens, she exits with a non-zero value. no drama, just numbers.


🧚 SEE ALSO 🧚


πŸ“ AUTHOR πŸ“

maintained by the LLVM Team (https://llvm.org/). they're doing the lord's work honestly.


2003-2025, LLVM Project


and that's the whole page, bestie πŸ’… this was LLC(1) from the LLVM project, dated 2025-09-03, page 20 of the manual. go compile something gorgeous. periodt. πŸ¦‹βœ¨

πŸ“¦ where this page comes from