aboutsummaryrefslogtreecommitdiff
path: root/lib/Frontend/CodeGenAction.cpp
AgeCommit message (Collapse)Author
2010-06-15Break Frontend's dependency on Rewrite, Checker and CodeGen in shared ↵Daniel Dunbar
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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106010 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-15fix the inline asm diagnostics to emit the error on the primary Chris Lattner
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 ^ git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105978 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-07Frontend: Add CodeGenAction support for handling LLVM IR. - This magically ↵Daniel Dunbar
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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105583 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-07Frontend: Drop unnecessary TargetData argument to EmitBackendOutput, we alwaysDaniel Dunbar
create modules which have target data strings. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105576 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-07Frontend: Factor clang::EmitBackendOutput out of CodeGenAction.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105575 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-07Frontend: Add CodeGenOptions::SimplifyLibCalls, and eliminate LangOptions ↵Daniel Dunbar
argument to BackendConsumer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105574 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-28Let the backend decide which scheduler and register allocator to use.Jakob Stoklund Olesen
Currently, the backend uses the same policy, but it will soon switch to -regalloc=fast for -O0. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104984 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-27Driver: Add clang -cc1 -mrelax-all option, which sets relaxes all ↵Daniel Dunbar
instructions when using -integrated-as. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104807 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-25Driver/Frontend: Add -emit-codegen-only, for running irgen + codegen but not theDaniel Dunbar
.s printer or .o writer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104623 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-13Rework when and how vtables are emitted, by tracking where vtables areDouglas Gregor
"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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103718 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-29Remove a FIXME that is unlikely to be fixed (streaming code generation).Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102623 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-29Frontend: Tie backend verification passes to CodeGenOptions::VerifyModule,Daniel Dunbar
instead of NDEBUG. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102622 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-19Fix -Wcast-qual warnings.Dan Gohman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101786 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-13add frontend support for -fdata-sections and -ffunction-sections,Chris Lattner
patch by Sylvere Teissier! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101108 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-08refactor out a function.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100733 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-06teach clang to install the inline asm diagnostic handler,Chris Lattner
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". git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100543 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-06reduce indentation, tidy.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100537 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-04Revert changes r97693, r97700, and r97718.John McCall
Our testing framework can't deal with disabled targets yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97719 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-04Create a TargetMachine whenever we create a CodeGenAction. The codegen ofJohn McCall
some builtins will rely on target knowledge. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97693 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-28Opt into the Verifier now that it's an opt-in feature ofDan Gohman
addPassesToEmitFile. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97358 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-25Move ~CodeGenAction out-of-line.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97166 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-25Frontend: Add CodeGenAction::takeModule().Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97111 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-25Frontend: Pull CodeGenAction out more, and eliminate CreateBackendConsumer.Daniel Dunbar
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97110 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-04-28 23:07:53 +0000