summaryrefslogtreecommitdiff
path: root/tools/lto/LTOCodeGenerator.cpp
Commit message (Collapse)AuthorAge
* Move LTO support library to a component, allowing it to be testedPeter Collingbourne2013-09-24
| | | | | | more reliably across platforms. Patch by Tom Roeder! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191343 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename some variables to match the style guide.Rafael Espindola2013-09-04
| | | | | | I am about to patch this code, and this makes the diff far more readable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189982 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename variables to match the style guide and clang-format.Rafael Espindola2013-09-04
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189962 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 189297, the original commit message is following. Shuxin Yang2013-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ---- Add new API lto_codegen_compile_parallel(). This API is proposed by Nick Kledzik. The semantic is: -------------------------------------------------------------------------- Generate code for merged module into an array of native object files. On success returns a pointer to an array of NativeObjectFile. The count parameter returns the number of elements in the array. Each element is a pointer/length for a generated mach-o/ELF buffer. The buffer is owned by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, or lto_codegen_compile() is called again. On failure, returns NULL (check lto_get_error_message() for details). extern const struct NativeObjectFile* lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count); --------------------------------------------------------------------------- This API is currently only called on OSX platform. Linux or other Unixes using GNU gold are not supposed to call this function, because on these systems, object files are fed back to linker via disk file instead of memory buffer. In this commit, lto_codegen_compile_parallel() simply calls lto_codegen_compile() to return a single object file. In the near future, this function is the entry point for compilation with partition. Linker can blindly call this function even if partition is turned off; in this case, compiler will return only one object file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189386 91177308-0d34-0410-b5e6-96231b3b80d8
* Add new API lto_codegen_compile_parallel().Shuxin Yang2013-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This API is proposed by Nick Kledzik. The semantic is: -------------------------------------------------------------------------- Generate code for merged module into an array of native object files. On success returns a pointer to an array of NativeObjectFile. The count parameter returns the number of elements in the array. Each element is a pointer/length for a generated mach-o/ELF buffer. The buffer is owned by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, or lto_codegen_compile() is called again. On failure, returns NULL (check lto_get_error_message() for details). extern const struct NativeObjectFile* lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count); --------------------------------------------------------------------------- This API is currently only called on OSX platform. Linux or other Unixes using GNU gold are not supposed to call this function, because on these systems, object files are fed back to linker via disk file instead of memory buffer. In this commit, lto_codegen_compile_parallel() simply calls lto_codegen_compile() to return a single object file. In the near future, this function is the entry point for compilation with partition. Linker can blindly call this function even if partition is turned off; in this case, compiler will return only one object file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189297 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r188188 and r188200.Shuxin Yang2013-08-12
| | | | | | | | | In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. Thank Eric for fixing a compile-warning. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188204 91177308-0d34-0410-b5e6-96231b3b80d8
* Misc enhancements to LTO:Shuxin Yang2013-08-12
| | | | | | | | | | | | | | | | | | | | | | 1. Add some helper classes for partitions. They are designed in a way such that the top-level LTO driver will not see much difference with or without partitioning. 2. Introduce work-dir. Now all intermediate files generated during LTO phases will be saved under work-dir. User can specify the workdir via -lto-workdir=/path/to/dir. By default the work-dir will be erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1. TODO: Erase the workdir, if the linker exit prematurely. We are currently not able to remove directory on signal. The support routines simply ignore directory. 3. Add one new API lto_codegen_get_files_need_remove(). Linker and LTO plugin will communicate via this API about which files (including directories) need to removed before linker exit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188188 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r185882. This is causing problems with the gold linker and might be ↵Bill Wendling2013-08-08
| | | | | | better handled by the linker. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188029 91177308-0d34-0410-b5e6-96231b3b80d8
* Change public functions of LTOCodeGenerator from ret-false-on-succ to ↵Shuxin Yang2013-08-07
| | | | | | | | | | | | ret-true-on-succ. As of this revision, all functions of LTOCodeGenerator are consistent in ret-true-on-succ. Tested on multiple OSes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187864 91177308-0d34-0410-b5e6-96231b3b80d8
* Change private functions of LTOCodeGenerator from ret-false-on-succ to ↵Shuxin Yang2013-08-06
| | | | | | ret-true-on-succ. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187819 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor FlattenCFG out from SimplifyCFGTom Stellard2013-08-06
| | | | | | Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Use parallel-and and parallel-or mode to consolidate branch ↵Tom Stellard2013-07-27
| | | | | | | | | | | | | | conditions Merge consecutive if-regions if they contain identical statements. Both transformations reduce number of branches. The transformation is guarded by a target-hook, and is currently enabled only for +R600, but the correctness has been tested on X86 target using a variety of CPU benchmarks. Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
* remove unnecessary spaceShuxin Yang2013-07-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186931 91177308-0d34-0410-b5e6-96231b3b80d8
* Initialize/Register LTO passes to enable flags like -print-after=<lto-pass>Shuxin Yang2013-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | There already have two "dead" functions, initialize{IPO|IPA}, defined for similar purpose. I decide not to call these two functions for two reasons: o. they don't cover all LTO passes (which will soon be separated into IPO and post-IPO passes) o. We have not yet figured out the right passes and the ordering for IPO and post-IPO stages, meaning this change is only for the time being. Since LTO passes are registered, we are now able to print IR before and after particular point. For OSX users: -------------- "...-Wl,-mllvm -Wl,-print-after=<pass-name>" will print IR after the specified pass. For Other UNIX with GNU gold linker: ------------------------------------ "-Wl,-plugin-opt=-print-after=<pass-name>" should work. (NOTE: no need for "-Wl,-mllvm") Strip "-Wl," if flags are fed directly to linker instead of clang/clang++. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186853 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a wrapper for open.Rafael Espindola2013-07-16
| | | | | | | This centralizes the handling of O_BINARY and opens the way for hiding more differences (like how open behaves with directories). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186447 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't run internalize if we're outputing bit-code and not an object file.Bill Wendling2013-07-08
| | | | | | | | | | | The problem with running internalize before we're ready to output an object file is that it may change a 'weak' symbol into an internal one, but that symbol could be needed by an external object file --- e.g. with arclite. <rdar://problem/14334895> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185882 91177308-0d34-0410-b5e6-96231b3b80d8
* Use sys::fs::createTemporaryFile.Rafael Espindola2013-07-05
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185719 91177308-0d34-0410-b5e6-96231b3b80d8
* Use pointers to the MCAsmInfo and MCRegInfo.Bill Wendling2013-06-18
| | | | | | | | | | Someone may want to do something crazy, like replace these objects if they change or something. No functionality change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184175 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't use PathV1.h in LTOCodeGenerator.cppRafael Espindola2013-06-17
| | | | | | | This patch also adds a simpler version of sys::fs::remove and a tool_output_file constructor for when we already have an open file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184095 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't use PathV1.h in Signals.h.Rafael Espindola2013-06-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183947 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't reach into the middle of TargetMachine and cache one of its ivars.Bill Wendling2013-05-29
| | | | | | | Not only does this break encapsulation, it's gross. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182876 91177308-0d34-0410-b5e6-96231b3b80d8
* The command line options need to be processed before we create the ↵Bill Wendling2013-05-23
| | | | | | | | | | | TargetMachine. Move the processing of the command line options to right before we create the TargetMachine instead of after. <rdar://problem/13468287> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182611 91177308-0d34-0410-b5e6-96231b3b80d8
* Last batch of cleanups to Linker.h.Rafael Espindola2013-05-04
| | | | | | | | Update comments, fix * placement, fix method names that are not used in clang, add a linkInModule that takes a Mode and put it in Linker.cpp. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181099 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't construct or delete a module on the Linker.Rafael Espindola2013-05-04
| | | | | | | The linker is now responsible only for actually linking the modules, it is up to the clients to create and destroy them. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181098 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused members and constructor arguments.Rafael Espindola2013-05-04
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181096 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't produce an empty llvm.compiler.used in LTO.Rafael Espindola2013-04-24
| | | | | | | | | | LTO was always creating an empty llvm.compiler.used. With this patch we now first check if there is anything to be added first. Unfortunately, there is no good way to test libLTO in isolation as it needs gold or ld64, but there are bots doing LTO builds that found this problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180202 91177308-0d34-0410-b5e6-96231b3b80d8
* Run the ObjCARCContract pass for LTO. <rdar://problem/13538084>Bob Wilson2013-03-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178385 91177308-0d34-0410-b5e6-96231b3b80d8
* Make LTO codegen use a PassManager, rather than a FunctionPassManager, for theLang Hames2013-03-13
| | | | | | | | | | | | | | | codegen passes. This brings it in to line with clang and llc's codegen setup, and tidies up the code. If I understand correctly, adding ModulePasses to a FunctionPassManager is bogus. It only seems to explode if an added ModulePass depends on a FunctionPass though, which might be why this code has survived so long. Fixes <rdar://problem/13386816>. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176977 91177308-0d34-0410-b5e6-96231b3b80d8
* Add the -disable-opt option to LTO. This adds:Bill Wendling2013-02-28
| | | | | | | | | | | | | | | - Consistency with opt (which supports the same option with the same meaning and description). - Debugging gold plugin-based linking without optimizations getting in the way. - Debugging programs linked with the gold plugin while preserving the original debug info. - Fine-grained control over LTO passes using the gold plugin in combination with opt (or clang/dragonegg). Patch by Cristiano Giuffrida! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176257 91177308-0d34-0410-b5e6-96231b3b80d8
* LTO: Also init TTI for codegen passes.Nadav Rotem2013-01-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172499 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch TargetTransformInfo from an immutable analysis pass that requiresChandler Carruth2013-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a TargetMachine to construct (and thus isn't always available), to an analysis group that supports layered implementations much like AliasAnalysis does. This is a pretty massive change, with a few parts that I was unable to easily separate (sorry), so I'll walk through it. The first step of this conversion was to make TargetTransformInfo an analysis group, and to sink the nonce implementations in ScalarTargetTransformInfo and VectorTargetTranformInfo into a NoTargetTransformInfo pass. This allows other passes to add a hard requirement on TTI, and assume they will always get at least on implementation. The TargetTransformInfo analysis group leverages the delegation chaining trick that AliasAnalysis uses, where the base class for the analysis group delegates to the previous analysis *pass*, allowing all but tho NoFoo analysis passes to only implement the parts of the interfaces they support. It also introduces a new trick where each pass in the group retains a pointer to the top-most pass that has been initialized. This allows passes to implement one API in terms of another API and benefit when some other pass above them in the stack has more precise results for the second API. The second step of this conversion is to create a pass that implements the TargetTransformInfo analysis using the target-independent abstractions in the code generator. This replaces the ScalarTargetTransformImpl and VectorTargetTransformImpl classes in lib/Target with a single pass in lib/CodeGen called BasicTargetTransformInfo. This class actually provides most of the TTI functionality, basing it upon the TargetLowering abstraction and other information in the target independent code generator. The third step of the conversion adds support to all TargetMachines to register custom analysis passes. This allows building those passes with access to TargetLowering or other target-specific classes, and it also allows each target to customize the set of analysis passes desired in the pass manager. The baseline LLVMTargetMachine implements this interface to add the BasicTTI pass to the pass manager, and all of the tools that want to support target-aware TTI passes call this routine on whatever target machine they end up with to add the appropriate passes. The fourth step of the conversion created target-specific TTI analysis passes for the X86 and ARM backends. These passes contain the custom logic that was previously in their extensions of the ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces. I separated them into their own file, as now all of the interface bits are private and they just expose a function to create the pass itself. Then I extended these target machines to set up a custom set of analysis passes, first adding BasicTTI as a fallback, and then adding their customized TTI implementations. The fourth step required logic that was shared between the target independent layer and the specific targets to move to a different interface, as they no longer derive from each other. As a consequence, a helper functions were added to TargetLowering representing the common logic needed both in the target implementation and the codegen implementation of the TTI pass. While technically this is the only change that could have been committed separately, it would have been a nightmare to extract. The final step of the conversion was just to delete all the old boilerplate. This got rid of the ScalarTargetTransformInfo and VectorTargetTransformInfo classes, all of the support in all of the targets for producing instances of them, and all of the support in the tools for manually constructing a pass based around them. Now that TTI is a relatively normal analysis group, two things become straightforward. First, we can sink it into lib/Analysis which is a more natural layer for it to live. Second, clients of this interface can depend on it *always* being available which will simplify their code and behavior. These (and other) simplifications will follow in subsequent commits, this one is clearly big enough. Finally, I'm very aware that much of the comments and documentation needs to be updated. As soon as I had this working, and plausibly well commented, I wanted to get it committed and in front of the build bots. I'll be doing a few passes over documentation later if it sticks. Commits to update DragonEgg and Clang will be made presently. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171681 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix another place where we build the TTI pass to the new interface.Chandler Carruth2013-01-05
| | | | | | Sorry for the noise here, 'make check' doesn't build this code. =/ git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171623 91177308-0d34-0410-b5e6-96231b3b80d8
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
* Sort a few more #include lines in tools/... unittests/... and utils/...Chandler Carruth2013-01-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171363 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm/tools: Add #include "llvm/TargetTransformInfo.h"NAKAMURA Takumi2012-12-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169817 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r169656.Bill Wendling2012-12-10
| | | | | | | | | The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that should be kept around. The linker will pretend that a dylib is being created. <rdar://problem/12528059> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169770 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert to old behavior until linker can pass export-dynamic option.Bill Wendling2012-12-10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169720 91177308-0d34-0410-b5e6-96231b3b80d8
* Add the `lto_codegen_set_export_dynamic' function.Bill Wendling2012-12-08
| | | | | | | | | | | | | | | | | | | | | | This function sets the `_exportDynamic' ivar. When that's set, we export all symbols (e.g. we don't run the internalize pass). This is equivalent to the `--export-dynamic' linker flag in GNU land: --export-dynamic When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time. If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself. The Darwin linker will support this via the `-export_dynamic' flag. We should modify clang to support this via the `-rdynamic' flag. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169656 91177308-0d34-0410-b5e6-96231b3b80d8
* Sort the #include lines for tools/...Chandler Carruth2012-12-04
| | | | | | | | Again, tools are trickier to pick the main module header for than library source files. I've started to follow the pattern of using LLVMContext.h when it is included as a stub for program source files. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169252 91177308-0d34-0410-b5e6-96231b3b80d8
* One more step towards making doInitialization and doFinalization useful forPedro Artigas2012-11-29
| | | | | | | | | start up and clean up module passes, now that ASAN and TSAN are fixed the tests pass git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168905 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r168635 "Step towards implementation of pass manager with ↵Owen Anderson2012-11-27
| | | | | | | | | doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model". It appears to have broken at least one buildbot. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168654 91177308-0d34-0410-b5e6-96231b3b80d8
* Step towards implementation of pass manager with doInitialization and ↵Owen Anderson2012-11-26
| | | | | | | | | doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model Patch by Pedro Artigas, with feedback from by Chandler Carruth. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168635 91177308-0d34-0410-b5e6-96231b3b80d8
* Add doInitialization and doFinalization methods to ModulePass's, to allow ↵Owen Anderson2012-11-15
| | | | | | | | | them to be re-initialized and reused on multiple Module's. Patch by Pedro Artigas. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168008 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply the TargerTransformInfo changes, minus the changes to LSR and ↵Nadav Rotem2012-10-18
| | | | | | Lowerinvoke. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166248 91177308-0d34-0410-b5e6-96231b3b80d8
* Temporarily revert the TargetTransform changes.Bob Wilson2012-10-18
| | | | | | | | | | | The TargetTransform changes are breaking LTO bootstraps of clang. I am working with Nadav to figure out the problem, but I am reverting it for now to get our buildbots working. This reverts svn commits: 165665 165669 165670 165786 165787 165997 and I have also reverted clang svn 165741 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166168 91177308-0d34-0410-b5e6-96231b3b80d8
* LTO also needs to initialize the TargetTransform infrastructure.Nadav Rotem2012-10-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165997 91177308-0d34-0410-b5e6-96231b3b80d8
* Set default CPU for Darwin targets with LTO. <rdar://problem/12457841>Bob Wilson2012-10-12
| | | | | | | | This is a temporary hack until Bill's project to record command line options in the LLVM IR is ready. Clang currently sets a default CPU but that isn't recorded anywhere and it doesn't get used in the final LTO compilation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165809 91177308-0d34-0410-b5e6-96231b3b80d8
* Move TargetData to DataLayout.Micah Villmow2012-10-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165403 91177308-0d34-0410-b5e6-96231b3b80d8
* Explicitly erase the file from disk if something bad happened. ↵Bill Wendling2012-09-06
| | | | | | <rdar://problem/12184899> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163349 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove some coding violations. No functionality change.Bill Wendling2012-08-08
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161530 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-06 16:26:31 +0000