Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 1 | =pod |
| 2 | |
| 3 | =head1 NAME |
| 4 | |
| 5 | llvmc - The LLVM Compiler Driver |
| 6 | |
| 7 | =head1 SYNOPSIS |
| 8 | |
| 9 | B<llvmc> [I<options>] [I<filenames>...] |
| 10 | |
| 11 | =head1 DESCRIPTION |
| 12 | |
| 13 | The B<llvmc> command is a configurable driver for invoking other |
| 14 | LLVM (and non-LLVM) tools in order to compile, optimize and link software |
| 15 | for multiple languages. For those familiar with the GNU Compiler |
| 16 | Collection's B<gcc> tool, it is very similar. This tool has the |
| 17 | following main goals or purposes: |
| 18 | |
| 19 | =over |
| 20 | |
| 21 | =item * A Single point of access to the LLVM tool set. |
| 22 | |
| 23 | =item * Hide the complexities of the LLVM tools through a single interface. |
| 24 | |
| 25 | =item * Make integration of existing non-LLVM tools simple. |
| 26 | |
| 27 | =item * Extend the capabilities of minimal front ends. |
| 28 | |
| 29 | =item * Make the interface for compiling consistent for all languages. |
| 30 | |
| 31 | =back |
| 32 | |
| 33 | The tool itself does nothing with a user's program. It merely invokes other |
| 34 | tools to get the compilation tasks done. |
| 35 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 36 | The options supported by B<llvmc> generalize the compilation process and |
| 37 | provide a consistent and simple interface for multiple programming languages. |
| 38 | This makes it easier for developers to get their software compiled with LLVM. |
| 39 | Without B<llvmc>, developers would need to understand how to invoke the |
| 40 | front-end compiler, optimizer, assembler, and linker in order to compile their |
| 41 | programs. B<llvmc>'s sole mission is to trivialize that process. |
| 42 | |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 43 | =head2 Basic Operation |
| 44 | |
| 45 | B<llvmc> always takes the following basic actions: |
| 46 | |
| 47 | =over |
| 48 | |
| 49 | =item * Command line options and filenames are collected. |
| 50 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 51 | The command line options provide the marching orders to B<llvmc> on what actions |
| 52 | it should perform. This is the I<request> the user is making of B<llvmc> and it |
| 53 | is interpreted first. |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 54 | |
| 55 | =item * Configuration files are read. |
| 56 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 57 | Based on the options and the suffixes of the filenames presented, a set of |
| 58 | configuration files are read to configure the actions B<llvmc> will take |
| 59 | (more on this later). |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 60 | |
| 61 | =item * Determine actions to take. |
| 62 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 63 | The tool chain needed to complete the task is determined. This is the primary |
| 64 | work of B<llvmc>. It breaks the request specified by the command line options |
| 65 | into a set of basic actions to be done: |
| 66 | |
| 67 | =over |
| 68 | |
| 69 | =item * Pre-processing: gathering/filtering compiler input |
| 70 | |
| 71 | =item * Compilation: source language to bytecode conversion |
| 72 | |
| 73 | =item * Assembly: bytecode to native code conversion |
| 74 | |
| 75 | =item * Optimization: conversion of bytecode to something that runs faster |
| 76 | |
| 77 | =item * Linking: combining multiple bytecodes to produce executable program |
| 78 | |
| 79 | =back |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 80 | |
| 81 | =item * Execute actions. |
| 82 | |
| 83 | The actions determined previously are executed sequentially and then |
| 84 | B<llvmc> terminates. |
| 85 | |
| 86 | =back |
| 87 | |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 88 | =head1 OPTIONS |
| 89 | |
| 90 | =head2 Control Options |
| 91 | |
| 92 | Control options tell B<llvmc> what to do at a high level. The |
| 93 | following control options are defined: |
| 94 | |
| 95 | =over |
| 96 | |
| 97 | =item B<-c> or B<--compile> |
| 98 | |
| 99 | This option specifies that the linking phase is not to be run. All |
| 100 | previous phases, if applicable will run. This is generally how a given |
| 101 | bytecode file is compiled and optimized for a source language module. |
| 102 | |
| 103 | =item B<-k> or B<--link> or default |
| 104 | |
| 105 | This option (or the lack of any control option) specifies that all stages |
| 106 | of compilation, optimization, and linking should be attempted. Source files |
| 107 | specified on the command line will be compiled and linked with objects and |
| 108 | libraries also specified. |
| 109 | |
| 110 | =item B<-S> or B<--assemble> |
| 111 | |
| 112 | This option specifies that compilation should end in the creation of |
| 113 | an LLVM assembly file that can be later converted to an LLVM object |
| 114 | file. |
| 115 | |
| 116 | =item B<-E> or B<--preprocess> |
| 117 | |
| 118 | This option specifies that no compilation or linking should be |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 119 | performed. Only pre-processing, if applicable to the language being |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 120 | compiled, is performed. For languages that support it, this will |
| 121 | result in the output containing the raw input to the compiler. |
| 122 | |
| 123 | =back |
| 124 | |
| 125 | =head2 Optimization Options |
| 126 | |
| 127 | Optimization with B<llvmc> is based on goals and specified with |
| 128 | the following -O options. The specific details of which |
| 129 | optimizations run is controlled by the configuration files because |
| 130 | each source language will have different needs. |
| 131 | |
| 132 | =over |
| 133 | |
| 134 | =item B<-O1> or B<-O0> (default, fast compilation) |
| 135 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 136 | Only those optimizations that will hasten the compilation (mostly by reducing |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 137 | the output) are applied. In general these are extremely fast and simple |
| 138 | optimizations that reduce emitted code size. The goal here is not to make the |
| 139 | resulting program fast but to make the compilation fast. If not specified, |
| 140 | this is the default level of optimization. |
| 141 | |
| 142 | =item B<-O2> (basic optimization) |
| 143 | |
| 144 | This level of optimization specifies a balance between generating good code |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 145 | that will execute reasonably quickly and not spending too much time optimizing |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 146 | the code to get there. For example, this level of optimization may include |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 147 | things like global common subexpression elimination, aggressive dead code |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 148 | elimination, and scalar replication. |
| 149 | |
| 150 | =item B<-O3> (aggressive optimization) |
| 151 | |
| 152 | This level of optimization aggressively optimizes each set of files compiled |
| 153 | together. However, no link-time inter-procedural optimization is performed. |
| 154 | This level implies all the optimizations of the B<-O1> and B<-O2> optimization |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 155 | levels, and should also provide loop optimizations and compile time |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 156 | inter-procedural optimizations. Essentially, this level tries to do as much |
| 157 | as it can with the input it is given but doesn't do any link time IPO. |
| 158 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 159 | =item B<-O4> (link time optimization) |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 160 | |
| 161 | In addition to the previous three levels of optimization, this level of |
| 162 | optimization aggressively optimizes each program at link time. It employs |
| 163 | basic analysis and basic link-time inter-procedural optimizations, |
| 164 | considering the program as a whole. |
| 165 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 166 | =item B<-O5> (aggressive link time optimization) |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 167 | |
| 168 | This is the same as B<-O4> except it employs aggressive analyses and |
| 169 | aggressive inter-procedural optimization. |
| 170 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 171 | =item B<-O6> (profile guided optimization: not implemented) |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 172 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 173 | This is the same as B<-O5> except that it employs profile-guided |
| 174 | re-optimization of the program after it has executed. Note that this implies |
| 175 | a single level of re-optimization based on runtime profile analysis. Once |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 176 | the re-optimization has completed, the profiling instrumentation is |
| 177 | removed and final optimizations are employed. |
| 178 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 179 | =item B<-O7> (lifelong optimization: not implemented) |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 180 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 181 | This is the same as B<-O5> and similar to B<-O6> except that re-optimization |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 182 | is performed through the life of the program. That is, each run will update |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 183 | the profile by which future re-optimizations are directed. |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 184 | |
| 185 | =back |
| 186 | |
| 187 | =head2 Input Options |
| 188 | |
| 189 | =over |
| 190 | |
| 191 | =item B<-l> I<LIBRARY> |
| 192 | |
| 193 | This option instructs B<llvmc> to locate a library named I<LIBRARY> and search |
| 194 | it for unresolved symbols when linking the program. |
| 195 | |
| 196 | =item B<-L> F<path> |
| 197 | |
| 198 | This option instructs B<llvmc> to add F<path> to the list of places in which |
| 199 | the linker will |
| 200 | |
| 201 | =item B<-x> I<LANGUAGE> |
| 202 | |
| 203 | This option instructs B<llvmc> to regard the following input files as |
| 204 | containing programs in the language I<LANGUAGE>. Normally, input file languages |
| 205 | are identified by their suffix but this option will override that default |
| 206 | behavior. The B<-x> option stays in effect until the end of the options or |
| 207 | a new B<-x> option is encountered. |
| 208 | |
| 209 | =back |
| 210 | |
| 211 | =head2 Output Options |
| 212 | |
| 213 | =over |
| 214 | |
| 215 | =item B<-m>I<arch> |
| 216 | |
| 217 | This option selects the back end code generator to use. The I<arch> portion |
| 218 | of the option names the back end to use. |
| 219 | |
| 220 | =item B<--native> |
| 221 | |
| 222 | Normally, B<llvmc> produces bytecode files at most stages of compilation. |
| 223 | With this option, B<llvmc> will arrange for native object files to be |
| 224 | generated with the B<-c> option, native assembly files to be generated |
| 225 | with the B<-S> option, and native executables to be generated with the |
| 226 | B<--link> option. In the case of the B<-E> option, the output will not |
| 227 | differ as there is no I<native> version of pre-processed output. |
| 228 | |
| 229 | =item B<-o> F<filename> |
| 230 | |
| 231 | Specify the output file name. The contents of the file depend on other |
| 232 | options. |
| 233 | |
| 234 | =back |
| 235 | |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 236 | =head2 Information Options |
| 237 | |
| 238 | =over |
| 239 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 240 | =item B<-n> or B<--no-op> |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 241 | |
| 242 | This option tells B<llvmc> to do everything but actually execute the |
| 243 | resulting tools. In combination with the B<-v> option, this causes B<llvmc> |
| 244 | to merely print out what it would have done. |
| 245 | |
| 246 | =item B<-v> or B<--verbose> |
| 247 | |
| 248 | This option will cause B<llvmc> to print out (on standard output) each of the |
| 249 | actions it takes to accomplish the objective. The output will immediately |
| 250 | precede the invocation of other tools. |
| 251 | |
| 252 | =item B<--stats> |
| 253 | |
| 254 | Print all statistics gathered during the compilation to the standard error. |
| 255 | Note that this option is merely passed through to the sub-tools to do with |
| 256 | as they please. |
| 257 | |
| 258 | =item B<--time-passes> |
| 259 | |
| 260 | Record the amount of time needed for each optimization pass and print it |
| 261 | to standard error. Like B<--stats> this option is just passed through to |
| 262 | the sub-tools to do with as they please. |
| 263 | |
| 264 | =item B<--time-programs> |
| 265 | |
| 266 | Record the amount of time each program (compilation tool) takes and print |
| 267 | it to the standard error. |
| 268 | |
| 269 | =back |
| 270 | |
| 271 | =head2 Language Specific Options |
| 272 | |
| 273 | =over |
| 274 | |
| 275 | |
| 276 | =item B<-Tool,opt>=I<options> |
| 277 | |
| 278 | Pass an arbitrary option to the optimizer. |
| 279 | |
| 280 | =item B<-Tool,link>=I<options> |
| 281 | |
| 282 | Pass an arbitrary option to the linker. |
| 283 | |
| 284 | =item B<-Tool,asm>=I<options> |
| 285 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 286 | Pass an arbitrary option to the code generator. |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 287 | |
| 288 | =back |
| 289 | |
| 290 | =head3 C/C++ Specific Options |
| 291 | |
| 292 | =over |
| 293 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 294 | =item B<-I>F<path> |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 295 | |
| 296 | This option is just passed through to a C or C++ front end compiler to tell it |
| 297 | where include files can be found. |
| 298 | |
| 299 | =back |
| 300 | |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 301 | =head2 Miscellaneous Options |
| 302 | |
| 303 | =over |
| 304 | |
| 305 | =item B<--help> |
| 306 | |
| 307 | Print a summary of command line options. |
| 308 | |
| 309 | =item B<-V> or B<--version> |
| 310 | |
| 311 | This option will cause B<llvmc> to print out its version number |
| 312 | and terminate. |
| 313 | |
| 314 | =back |
| 315 | |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 316 | =head2 Advanced Options |
| 317 | |
| 318 | You better know what you're doing if you use these options. Improper use |
| 319 | of these options can produce drastically wrong results. |
| 320 | |
| 321 | =over |
| 322 | |
| 323 | =item B<--show-config> I<[suffixes...]> |
| 324 | |
| 325 | When this option is given, the only action taken by B<llvmc> is to show its |
| 326 | final configuration state in the form of a configuration file. No compilation |
| 327 | tasks will be conducted when this option is given; processing will stop once |
| 328 | the configuration has been printed. The optional (comma separated) list of |
| 329 | suffixes controls what is printed. Without any suffixes, the configuration |
| 330 | for all languages is printed. With suffixes, only the languages pertaining |
| 331 | to those file suffixes will be printed. The configuration information is |
| 332 | printed after all command line options and configuration files have been |
| 333 | read and processed. This allows the user to verify that the correct |
| 334 | configuration data has been read by B<llvmc>. |
| 335 | |
| 336 | =item B<--config> :I<section>:I<name>=I<value> |
| 337 | |
| 338 | This option instructs B<llvmc> to accept I<value> as the value for configuration |
| 339 | item I<name> in the section named I<section>. This is a quick way to override |
| 340 | a configuration item on the command line without resorting to changing the |
| 341 | configuration files. |
| 342 | |
| 343 | =item B<--config-file> F<dirname> |
| 344 | |
| 345 | This option tells B<llvmc> to read configuration data from the I<directory> |
| 346 | named F<dirname>. Data from such directories will be read in the order |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 347 | specified on the command line after all other standard configuration files have |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 348 | been read. This allows users or groups of users to conveniently create |
| 349 | their own configuration directories in addition to the standard ones to which |
| 350 | they may not have write access. |
| 351 | |
| 352 | =item B<--config-only-from> F<dirname> |
| 353 | |
| 354 | This option tells B<llvmc> to skip the normal processing of configuration |
| 355 | files and only configure from the contents of the F<dirname> directory. Multiple |
| 356 | B<--config-only-from> options may be given in which case the directories are |
| 357 | read in the order given on the command line. |
| 358 | |
| 359 | |
| 360 | =item B<--emit-raw-code> |
| 361 | |
| 362 | No optimization is done whatsoever. The compilers invoked by B<llvmc> with |
| 363 | this option given will be instructed to produce raw, unoptimized code. This |
| 364 | option is useful only to front end language developers and therefore does not |
| 365 | participate in the list of B<-O> options. This is distinctly different from |
| 366 | the B<-O0> option (a synonym for B<-O1>) because those optimizations will |
| 367 | reduce code size to make compilation faster. With B<--emit-raw-code>, only |
| 368 | the full raw code produced by the compiler will be generated. |
| 369 | |
| 370 | =back |
| 371 | |
| 372 | =head1 CONFIGURATION |
| 373 | |
| 374 | =head2 Warning |
| 375 | |
| 376 | Configuration information is relatively static for a given release of LLVM and |
| 377 | a front end compiler. However, the details may change from release to release. |
| 378 | Users are encouraged to simply use the various options of the B<llvmc> command |
| 379 | and ignore the configuration of the tool. These configuration files are for |
| 380 | compiler writers and LLVM developers. Those wishing to simply use B<llvmc> |
| 381 | don't need to understand this section but it may be instructive on what the tool |
| 382 | does. |
| 383 | |
| 384 | =head2 Introduction |
| 385 | |
| 386 | B<llvmc> is highly configurable both on the command line and in configuration |
| 387 | files. The options it understands are generic, consistent and simple by design. |
| 388 | Furthermore, the B<llvmc> options apply to the compilation of any LLVM enabled |
| 389 | programming language. To be enabled as a supported source language compiler, a |
| 390 | compiler writer must provide a configuration file that tells B<llvmc> how to |
| 391 | invoke the compiler and what its capabilities are. The purpose of the |
| 392 | configuration files then is to allow compiler writers to specify to B<llvmc> how |
| 393 | the compiler should be invoked. Users may but are not advised to alter the |
| 394 | compiler's B<llvmc> configuration. |
| 395 | |
| 396 | Because B<llvmc> just invokes other programs, it must deal with the |
| 397 | available command line options for those programs regardless of whether they |
| 398 | were written for LLVM or not. Furthermore, not all compilation front ends will |
| 399 | have the same capabilities. Some front ends will simply generate LLVM assembly |
| 400 | code, others will be able to generate fully optimized byte code. In general, |
| 401 | B<llvmc> doesn't make any assumptions about the capabilities or command line |
| 402 | options of a sub-tool. It simply uses the details found in the configuration |
| 403 | files and leaves it to the compiler writer to specify the configuration |
| 404 | correctly. |
| 405 | |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 406 | This approach means that new compiler front ends can be up and working very |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 407 | quickly. As a first cut, a front end can simply compile its source to raw |
| 408 | (unoptimized) bytecode or LLVM assembly and B<llvmc> can be configured to pick |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 409 | up the slack (translate LLVM assembly to bytecode, optimize the bytecode, |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 410 | generate native assembly, link, etc.). In fact, the front end need not use |
| 411 | any LLVM libraries, and it could be written in any language (instead of C++). |
| 412 | The configuration data will allow the full range of optimization, assembly, |
| 413 | and linking capabilities that LLVM provides to be added to these kinds of tools. |
| 414 | Enabling the rapid development of front-ends is one of the primary goals of |
| 415 | B<llvmc>. |
| 416 | |
| 417 | As a compiler front end matures, it may utilize the LLVM libraries and tools to |
| 418 | more efficiently produce optimized bytecode directly in a single compilation and |
| 419 | optimization program. In these cases, multiple tools would not be needed and |
| 420 | the configuration data for the compiler would change. |
| 421 | |
| 422 | Configuring B<llvmc> to the needs and capabilities of a source language compiler |
| 423 | is relatively straight forward. The compilation process is broken down into five |
| 424 | phases: |
| 425 | |
| 426 | =over |
| 427 | |
| 428 | =item * Pre-processing (filter and combine source files) |
| 429 | |
| 430 | =item * Translation (translate source language to LLVM assembly or bytecode) |
| 431 | |
| 432 | =item * Optimization (make bytecode execute quickly) |
| 433 | |
| 434 | =item * Assembly (converting bytecode to object code) |
| 435 | |
| 436 | =item * Linking (converting translated code to an executable) |
| 437 | |
| 438 | =back |
| 439 | |
| 440 | A compiler writer must provide a definition of what to do for each of these five |
| 441 | phases for each of the optimization levels. The specification consists simply of |
| 442 | prototypical command lines into which B<llvmc> can substitute command line |
| 443 | arguments and file names. Note that any given phase can be completely blank if |
| 444 | the source language's compiler combines multiple phases into a single program. |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 445 | For example, quite often pre-processing, translation, and optimization are |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 446 | combined into a single program. The specification for such a compiler would have |
| 447 | blank entries for pre-processing and translation but a full command line for |
| 448 | optimization. |
| 449 | |
| 450 | =head2 Configuration File Types |
| 451 | |
| 452 | There are two types of configuration files: the master configuration file |
| 453 | and the language specific configuration file. |
| 454 | |
| 455 | The master configuration file contains the general configuration of B<llvmc> |
| 456 | itself. This includes things like the mapping between file extensions and |
| 457 | source languages. This mapping is needed in order to quickly read only the |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 458 | applicable language-specific configuration files (avoiding reading every |
| 459 | configuration file for every compilation task). |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 460 | |
| 461 | Language specific configuration files tell B<llvmc> how to invoke the language's |
| 462 | compiler for a variety of different tasks and what other tools are needed to |
| 463 | I<backfill> the compiler's missing features (e.g. optimization). |
| 464 | |
| 465 | Language specific configuration files are placed in directories and given |
| 466 | specific names to foster faster lookup. The name of a given configuration file |
| 467 | is the name of the source language. |
| 468 | |
| 469 | =head2 Default Directory Locations |
| 470 | |
| 471 | B<llvmc> will look for configuration files in two standard locations: the |
| 472 | LLVM installation directory (typically C</usr/local/llvm/etc>) and the user's |
Reid Spencer | f9cdefb | 2004-08-06 22:56:49 +0000 | [diff] [blame] | 473 | home directory (typically C</home/user/.llvm>). In these directories a file |
| 474 | named C<master> provides the master configuration for B<llvmc>. Language |
| 475 | specific files will have a language specific name (e.g. C++, Stacker, Scheme, |
| 476 | FORTRAN). When reading the configuration files, the master files are always |
| 477 | read first in the following order: |
Reid Spencer | f2edda0 | 2004-08-06 22:28:47 +0000 | [diff] [blame] | 478 | |
| 479 | =over |
| 480 | |
| 481 | =item 1 C<master> in LLVM installation directory |
| 482 | |
| 483 | =item 2 C<master> in the user's home directory. |
| 484 | |
| 485 | =back |
| 486 | |
| 487 | Then, based on the command line options and the suffixes of the file names |
| 488 | provided on B<llvmc>'s command line, one or more language specific configuration |
| 489 | files are read. Only the language specific configuration files actually needed |
| 490 | to complete B<llvmc>'s task are read. Other language specific files will be |
| 491 | ignored. |
| 492 | |
| 493 | Note that the user can affect this process in several ways using the various |
| 494 | B<--config-*> options and with the B<--x LANGUAGE> option. |
| 495 | |
| 496 | Although a user I<can> override the master configuration file, this is not |
| 497 | advised. The capability is retained so that compiler writers can affect the |
| 498 | master configuration (such as adding new file suffixes) while developing a new |
| 499 | compiler front end since they might not have write access to the installed |
| 500 | master configuration. |
| 501 | |
| 502 | =head2 Syntax |
| 503 | |
| 504 | The syntax of the configuration files is yet to be determined. There are three |
| 505 | viable options: |
| 506 | |
| 507 | =over |
| 508 | |
| 509 | =item XML |
| 510 | =item Windows .ini |
| 511 | =item specific to B<llvmc> |
| 512 | |
| 513 | =back |
| 514 | |
Reid Spencer | be65afb | 2004-08-06 16:58:48 +0000 | [diff] [blame] | 515 | =head1 EXIT STATUS |
| 516 | |
| 517 | If B<llvmc> succeeds, it will exit with 0. Otherwise, if an error |
| 518 | occurs, it will exit with a non-zero value and no compilation actions |
| 519 | will be taken. If one of the compilation tools returns a non-zero |
| 520 | status, pending actions will be discarded and B<llvmc> will return the |
| 521 | same result code as the failing compilation tool. |
| 522 | |
| 523 | =head1 SEE ALSO |
| 524 | |
| 525 | L<gccas|gccas>, L<gccld|gccld>, L<llvm-as|llvm-as>, L<llvm-dis|llvm-dis>, |
| 526 | L<llc|llc>, L<llvm-link|llvm-link> |
| 527 | |
| 528 | =head1 AUTHORS |
| 529 | |
| 530 | Reid Spencer |
| 531 | |
| 532 | =cut |