summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CodeGenAction.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Break Frontend's dependency on Rewrite, Checker and CodeGen in shared ↵Daniel Dunbar2010-06-151-349/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | library configuration Currently, all AST consumers are located in the Frontend library, meaning that in a shared library configuration, Frontend has a dependency on Rewrite, Checker and CodeGen. This is suboptimal for clients which only wish to make use of the frontend. CodeGen in particular introduces a large number of unwanted dependencies. This patch breaks the dependency by moving all AST consumers with dependencies on Rewrite, Checker and/or CodeGen to their respective libraries. The patch therefore introduces dependencies in the other direction (i.e. from Rewrite, Checker and CodeGen to Frontend). After applying this patch, Clang builds correctly using CMake and shared libraries ("cmake -DBUILD_SHARED_LIBS=ON"). N.B. This patch includes file renames which are indicated in the patch body. Changes in this revision of the patch: - Fixed some copy-paste mistakes in the header files - Modified certain aspects of the coding to comply with the LLVM Coding Standards llvm-svn: 106010
* fix the inline asm diagnostics to emit the error on the primary Chris Lattner2010-06-151-8/+17
| | | | | | | | | | | | | | | | | | | | | | source code location instead of on the note. Previously we generated: <inline asm>:1:2: error: unrecognized instruction barf ^ t.c:4:8: note: generated from here asm ("barf"); ^ Now we generate: t.c:4:8: error: unrecognized instruction asm ("barf"); ^ <inline asm>:1:2: note: instantated into assembly here barf ^ llvm-svn: 105978
* Frontend: Add CodeGenAction support for handling LLVM IR.Daniel Dunbar2010-06-071-14/+74
| | | | | | | | | | | | | | | | | - This magically enables using 'clang -cc1' as a replacement for most of 'llvm-as', 'llvm-dis', 'llc' and 'opt' functionality. For example, 'llvm-as' is: $ clang -cc1 -emit-llvm-bc FOO.ll -o FOO.bc and 'llvm-dis' is: $ clang -cc1 -emit-llvm FOO.bc -o - and 'opt' is, e.g.: $ clang -cc1 -emit-llvm -O3 -o FOO.opt.ll FOO.ll and 'llc' is, e.g.: $ clang -cc1 -S -o - FOO.ll The nice thing about using the backend tools this way is that they are guaranteed to exactly match how the compiler generates code (for example, setting the same backend options). llvm-svn: 105583
* Frontend: Drop unnecessary TargetData argument to EmitBackendOutput, we alwaysDaniel Dunbar2010-06-071-11/+4
| | | | | | create modules which have target data strings. llvm-svn: 105576
* Frontend: Factor clang::EmitBackendOutput out of CodeGenAction.Daniel Dunbar2010-06-071-327/+30
| | | | llvm-svn: 105575
* Frontend: Add CodeGenOptions::SimplifyLibCalls, and eliminate LangOptions ↵Daniel Dunbar2010-06-071-5/+3
| | | | | | argument to BackendConsumer. llvm-svn: 105574
* Let the backend decide which scheduler and register allocator to use.Jakob Stoklund Olesen2010-05-281-7/+0
| | | | | | | Currently, the backend uses the same policy, but it will soon switch to -regalloc=fast for -O0. llvm-svn: 104984
* Driver: Add clang -cc1 -mrelax-all option, which sets relaxes all ↵Daniel Dunbar2010-05-271-0/+3
| | | | | | instructions when using -integrated-as. llvm-svn: 104807
* Driver/Frontend: Add -emit-codegen-only, for running irgen + codegen but not theDaniel Dunbar2010-05-251-0/+8
| | | | | | .s printer or .o writer. llvm-svn: 104623
* Rework when and how vtables are emitted, by tracking where vtables areDouglas Gregor2010-05-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "used" (e.g., we will refer to the vtable in the generated code) and when they are defined (i.e., because we've seen the key function definition). Previously, we were effectively tracking "potential definitions" rather than uses, so we were a bit too eager about emitting vtables for classes without key functions. The new scheme: - For every use of a vtable, Sema calls MarkVTableUsed() to indicate the use. For example, this occurs when calling a virtual member function of the class, defining a constructor of that class type, dynamic_cast'ing from that type to a derived class, casting to/through a virtual base class, etc. - For every definition of a vtable, Sema calls MarkVTableUsed() to indicate the definition. This happens at the end of the translation unit for classes whose key function has been defined (so we can delay computation of the key function; see PR6564), and will also occur with explicit template instantiation definitions. - For every vtable defined/used, we mark all of the virtual member functions of that vtable as defined/used, unless we know that the key function is in another translation unit. This instantiates virtual member functions when needed. - At the end of the translation unit, Sema tells CodeGen (via the ASTConsumer) which vtables must be defined (CodeGen will define them) and which may be used (for which CodeGen will define the vtables lazily). From a language perspective, both the old and the new schemes are permissible: we're allowed to instantiate virtual member functions whenever we want per the standard. However, all other C++ compilers were more lazy than we were, and our eagerness was both a performance issue (we instantiated too much) and a portability problem (we broke Boost test cases, which now pass). Notes: (1) There's a ton of churn in the tests, because the order in which vtables get emitted to IR has changed. I've tried to isolate some of the larger tests from these issues. (2) Some diagnostics related to implicitly-instantiated/implicitly-defined virtual member functions have moved to the point of first use/definition. It's better this way. (3) I could use a review of the places where we MarkVTableUsed, to see if I missed any place where the language effectively requires a vtable. Fixes PR7114 and PR6564. llvm-svn: 103718
* Remove a FIXME that is unlikely to be fixed (streaming code generation).Daniel Dunbar2010-04-291-20/+16
| | | | llvm-svn: 102623
* Frontend: Tie backend verification passes to CodeGenOptions::VerifyModule,Daniel Dunbar2010-04-291-9/+1
| | | | | | instead of NDEBUG. llvm-svn: 102622
* Fix -Wcast-qual warnings.Dan Gohman2010-04-191-1/+1
| | | | llvm-svn: 101786
* add frontend support for -fdata-sections and -ffunction-sections,Chris Lattner2010-04-131-0/+3
| | | | | | patch by Sylvere Teissier! llvm-svn: 101108
* refactor out a function.Chris Lattner2010-04-081-24/+29
| | | | llvm-svn: 100733
* teach clang to install the inline asm diagnostic handler,Chris Lattner2010-04-061-2/+74
| | | | | | | | | | | | | | | | | allowing backend errors to be mapped through clang's diagnostics subsystem, including the backend location info. We now get: $ clang asm.c -c -o t.o -integrated-as <inline asm>:1:2: error: unrecognized instruction abc incl %eax ^ 1 diagnostic generated. With colors, and correct "# diagnostics generated". llvm-svn: 100543
* reduce indentation, tidy.Chris Lattner2010-04-061-114/+121
| | | | llvm-svn: 100537
* Revert changes r97693, r97700, and r97718.John McCall2010-03-041-72/+54
| | | | | | Our testing framework can't deal with disabled targets yet. llvm-svn: 97719
* Create a TargetMachine whenever we create a CodeGenAction. The codegen ofJohn McCall2010-03-041-54/+72
| | | | | | some builtins will rely on target knowledge. llvm-svn: 97693
* Opt into the Verifier now that it's an opt-in feature ofDan Gohman2010-02-281-1/+10
| | | | | | addPassesToEmitFile. llvm-svn: 97358
* Move ~CodeGenAction out-of-line.Daniel Dunbar2010-02-251-0/+2
| | | | llvm-svn: 97166
* Frontend: Add CodeGenAction::takeModule().Daniel Dunbar2010-02-251-8/+26
| | | | llvm-svn: 97111
* Frontend: Pull CodeGenAction out more, and eliminate CreateBackendConsumer.Daniel Dunbar2010-02-251-0/+474
This is the way I would like to move the frontend function towards -- distinct pieces of functionality should be exposed only via FrontendAction implementations which have clean and relatively-stable APIs. This also isolates the surface area in clang which depends on LLVM CodeGen. llvm-svn: 97110
OpenPOWER on IntegriCloud