summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/TargetMachine.cpp
Commit message (Collapse)AuthorAgeFilesLines
* constify the Function parameter to the TTI creation callback andEric Christopher2015-09-161-1/+1
| | | | | | propagate to all callers/users/etc. llvm-svn: 247864
* Make TargetTransformInfo keeping a reference to the Module DataLayoutMehdi Amini2015-07-091-2/+3
| | | | | | | | | | | | | | | | | | | | DataLayout is no longer optional. It was initialized with or without a DataLayout, and the DataLayout when supplied could have been the one from the TargetMachine. Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11021 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 241774
* Replace string GNU Triples with llvm::Triple in TargetMachine. NFC.Daniel Sanders2015-06-111-1/+1
| | | | | | | | | | | | | | | | | | Summary: For the moment, TargetMachine::getTargetTriple() still returns a StringRef. This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rengolin Reviewed By: rengolin Subscribers: ted, llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10362 llvm-svn: 239554
* Remove DisableTailCalls from TargetOptions and the code in resetTargetOptionsAkira Hatanaka2015-06-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | that was resetting it. Remove the uses of DisableTailCalls in subclasses of TargetLowering and use the value of function attribute "disable-tail-calls" instead. Also, unconditionally add pass TailCallElim to the pipeline and check the function attribute at the start of runOnFunction to disable the pass on a per-function basis. This is part of the work to remove TargetMachine::resetTargetOptions, and since DisableTailCalls was the last non-fast-math option that was being reset in that function, we should be able to remove the function entirely after the work to propagate IR-level fast-math flags to DAG nodes is completed. Out-of-tree users should remove the uses of DisableTailCalls and make changes to attach attribute "disable-tail-calls"="true" or "false" to the functions in the IR. rdar://problem/13752163 Differential Revision: http://reviews.llvm.org/D10099 llvm-svn: 239427
* Bump SmallString to the minimum required amount for raw_ostream to avoid ↵Benjamin Kramer2015-05-231-1/+1
| | | | | | | | allocation. NFC. llvm-svn: 238104
* Stop resetting NoFramePointerElim in TargetMachine::resetTargetOptions.Akira Hatanaka2015-05-231-1/+0
| | | | | | | | | | | | | | This is part of the work to remove TargetMachine::resetTargetOptions. In this patch, instead of updating global variable NoFramePointerElim in resetTargetOptions, its use in DisableFramePointerElim is replaced with a call to TargetFrameLowering::noFramePointerElim. This function determines on a per-function basis if frame pointer elimination should be disabled. There is no change in functionality except that cl:opt option "disable-fp-elim" can now override function attribute "no-frame-pointer-elim". llvm-svn: 238080
* MC: Clean up method names in MCContext.Jim Grosbach2015-05-181-1/+1
| | | | | | | The naming was a mish-mash of old and new style. Update to be consistent with the new. NFC. llvm-svn: 237594
* Stop resetting SanitizeAddress in TargetMachine::resetTargetOptions. NFC.Akira Hatanaka2015-05-151-2/+0
| | | | | | | | | | | | | | Instead of doing that, create a temporary copy of MCTargetOptions and reset its SanitizeAddress field based on the function's attribute every time an InlineAsm instruction is emitted in AsmPrinter::EmitInlineAsm. This is part of the work to remove TargetMachine::resetTargetOptions (the FIXME added to TargetMachine.cpp in r236009 explains why this function has to be removed). Differential Revision: http://reviews.llvm.org/D9570 llvm-svn: 237412
* Migrate existing backends that care about software floating pointEric Christopher2015-05-121-1/+0
| | | | | | | | | | | | | | | | | | | | to use the information in the module rather than TargetOptions. We've had and clang has used the use-soft-float attribute for some time now so have the backends set a subtarget feature based on a particular function now that subtargets are created based on functions and function attributes. For the one middle end soft float check go ahead and create an overloadable TargetLowering::useSoftFloat function that just checks the TargetSubtargetInfo in all cases. Also remove the command line option that hard codes whether or not soft-float is set by using the attribute for all of the target specific test cases - for the generic just go ahead and add the attribute in the one case that showed up. llvm-svn: 237079
* Add a fixme to resetTargetOptions to explain why it needs to goEric Christopher2015-04-281-0/+5
| | | | | | away. llvm-svn: 236009
* Remove superfluous .str() and replace std::string concatenation with Twine.Yaron Keren2015-03-271-1/+1
| | | | llvm-svn: 233392
* Add an MCSubtargetInfo variable to the TargetMachine.Eric Christopher2015-03-191-1/+3
| | | | | | | | | This enables us to remove calls to the subtarget from the TargetMachine and with a small hack for backends that require global subtarget information for module level code generation, e.g. mips abi flags, as mentioned in a fixme in the code. llvm-svn: 232776
* Add a TargetMachine local MCRegisterInfo and MCInstrInfo so thatEric Christopher2015-03-191-2/+5
| | | | | | | they can be used without a subtarget in constructing subtarget independent passes. llvm-svn: 232775
* Revert "Add a TargetMachine local MCRegisterInfo and MCInstrInfo so that"Eric Christopher2015-03-181-4/+2
| | | | | | | | Committed too early. This reverts commit r232666. llvm-svn: 232667
* Add a TargetMachine local MCRegisterInfo and MCInstrInfo so thatEric Christopher2015-03-181-2/+4
| | | | | | | they can be used without a subtarget in constructing subtarget independent passes. llvm-svn: 232666
* COFF: Let globals with private linkage reside in their own sectionDavid Majnemer2015-03-171-1/+1
| | | | | | | | | | COFF COMDATs (for selection kinds other than 'select any') require at least one non-section symbol in the symbol table. Satisfy this by morally enhancing the linkage from private to internal. Differential Revision: http://reviews.llvm.org/D8394 llvm-svn: 232570
* Revert "COFF: Let globals with private linkage reside in their own section"David Majnemer2015-03-171-1/+1
| | | | | | This reverts commit r232539. This was committed accidently. llvm-svn: 232543
* COFF: Let globals with private linkage reside in their own sectionDavid Majnemer2015-03-171-1/+1
| | | | | | | | | | | | | | | Summary: COFF COMDATs (for selection kinds other than 'select any') require at least one non-section symbol in the symbol table. Satisfy this by morally enhancing the linkage from private to internal. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8374 llvm-svn: 232539
* Move the DataLayout to the generic TargetMachine, making it mandatory.Mehdi Amini2015-03-121-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I don't know why every singled backend had to redeclare its own DataLayout. There was a virtual getDataLayout() on the common base TargetMachine, the default implementation returned nullptr. It was not clear from this that we could assume at call site that a DataLayout will be available with each Target. Now getDataLayout() is no longer virtual and return a pointer to the DataLayout member of the common base TargetMachine. I plan to turn it into a reference in a future patch. The only backend that didn't have a DataLayout previsouly was the CPPBackend. It now initializes the default DataLayout. This commit is NFC for all the other backends. Test Plan: clang+llvm ninja check-all Reviewers: echristo Subscribers: jfb, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D8243 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231987
* Target: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-4/+2
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229261
* [PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth2015-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
* Remove mostly unused setters.Rafael Espindola2015-02-121-24/+0
| | | | | | Most of the code was setting the TargetOptions directly. llvm-svn: 228961
* Only access TLOF via the TargetMachine, not TargetLowering.Eric Christopher2015-02-031-6/+4
| | | | llvm-svn: 227949
* [multiversion] Switch all of the targets over to use theChandler Carruth2015-02-011-8/+2
| | | | | | | | | | | | | | | | TargetIRAnalysis access path directly rather than implementing getTTI. This even removes getTTI from the interface. It's more efficient for each target to just register a precise callback that creates their specific TTI. As part of this, all of the targets which are building their subtargets individually per-function now build their TTI instance with the function and thus look up the correct subtarget and cache it. NVPTX, R600, and XCore currently don't leverage this functionality, but its trivial for them to add it now. llvm-svn: 227735
* [PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis toChandler Carruth2015-02-011-0/+7
| | | | | | | | | | | | | | produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
* [PM] Switch the TargetMachine interface from accepting a pass managerChandler Carruth2015-01-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | base which it adds a single analysis pass to, to instead return the type erased TargetTransformInfo object constructed for that TargetMachine. This removes all of the pass variants for TTI. There is now a single TTI *pass* in the Analysis layer. All of the Analysis <-> Target communication is through the TTI's type erased interface itself. While the diff is large here, it is nothing more that code motion to make types available in a header file for use in a different source file within each target. I've tried to keep all the doxygen comments and file boilerplate in line with this move, but let me know if I missed anything. With this in place, the next step to making TTI work with the new pass manager is to introduce a really simple new-style analysis that produces a TTI object via a callback into this routine on the target machine. Once we have that, we'll have the building blocks necessary to accept a function argument as well. llvm-svn: 227685
* [PM] Change the core design of the TTI analysis to use a polymorphicChandler Carruth2015-01-311-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | type erased interface and a single analysis pass rather than an extremely complex analysis group. The end result is that the TTI analysis can contain a type erased implementation that supports the polymorphic TTI interface. We can build one from a target-specific implementation or from a dummy one in the IR. I've also factored all of the code into "mix-in"-able base classes, including CRTP base classes to facilitate calling back up to the most specialized form when delegating horizontally across the surface. These aren't as clean as I would like and I'm planning to work on cleaning some of this up, but I wanted to start by putting into the right form. There are a number of reasons for this change, and this particular design. The first and foremost reason is that an analysis group is complete overkill, and the chaining delegation strategy was so opaque, confusing, and high overhead that TTI was suffering greatly for it. Several of the TTI functions had failed to be implemented in all places because of the chaining-based delegation making there be no checking of this. A few other functions were implemented with incorrect delegation. The message to me was very clear working on this -- the delegation and analysis group structure was too confusing to be useful here. The other reason of course is that this is *much* more natural fit for the new pass manager. This will lay the ground work for a type-erased per-function info object that can look up the correct subtarget and even cache it. Yet another benefit is that this will significantly simplify the interaction of the pass managers and the TargetMachine. See the future work below. The downside of this change is that it is very, very verbose. I'm going to work to improve that, but it is somewhat an implementation necessity in C++ to do type erasure. =/ I discussed this design really extensively with Eric and Hal prior to going down this path, and afterward showed them the result. No one was really thrilled with it, but there doesn't seem to be a substantially better alternative. Using a base class and virtual method dispatch would make the code much shorter, but as discussed in the update to the programmer's manual and elsewhere, a polymorphic interface feels like the more principled approach even if this is perhaps the least compelling example of it. ;] Ultimately, there is still a lot more to be done here, but this was the huge chunk that I couldn't really split things out of because this was the interface change to TTI. I've tried to minimize all the other parts of this. The follow up work should include at least: 1) Improving the TargetMachine interface by having it directly return a TTI object. Because we have a non-pass object with value semantics and an internal type erasure mechanism, we can narrow the interface of the TargetMachine to *just* do what we need: build and return a TTI object that we can then insert into the pass pipeline. 2) Make the TTI object be fully specialized for a particular function. This will include splitting off a minimal form of it which is sufficient for the inliner and the old pass manager. 3) Add a new pass manager analysis which produces TTI objects from the target machine for each function. This may actually be done as part of #2 in order to use the new analysis to implement #2. 4) Work on narrowing the API between TTI and the targets so that it is easier to understand and less verbose to type erase. 5) Work on narrowing the API between TTI and its clients so that it is easier to understand and less verbose to forward. 6) Try to improve the CRTP-based delegation. I feel like this code is just a bit messy and exacerbating the complexity of implementing the TTI in each target. Many thanks to Eric and Hal for their help here. I ended up blocked on this somewhat more abruptly than I expected, and so I appreciate getting it sorted out very quickly. Differential Revision: http://reviews.llvm.org/D7293 llvm-svn: 227669
* Recommit r224935 with a fix for the ObjC++/AArch64 bug that that revisionLang Hames2015-01-091-1/+15
| | | | | | | | | | introduced. A test case for the bug was already committed in r225385. Patch by Rafael Espindola. llvm-svn: 225534
* Revert r224935 "Refactor duplicated code. No intended functionality change."Lang Hames2015-01-061-2/+1
| | | | | | | | This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin. Reverting to get the bots green while I track down the source of the changed behavior. llvm-svn: 225311
* Refactor duplicated code.Rafael Espindola2014-12-291-1/+2
| | | | | | No intended functionality change. llvm-svn: 224935
* Move resetTargetOptions from taking a MachineFunction to a FunctionEric Christopher2014-09-261-12/+8
| | | | | | | since we are accessing the TargetMachine that we're a member function of. llvm-svn: 218489
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+3
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-281-9/+6
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Use alias linkage and visibility to decide tls access mode.Rafael Espindola2014-05-231-13/+10
| | | | | | | | | | | | | | | | | This matches both what we do for the non-thread case and what gcc does. With this patch clang would match gcc's behaviour in static __thread int a = 42; extern __thread int b __attribute__((alias("a"))); int *f(void) { return &a; } int *g(void) { return &b; } if not for pr19843. Manually writing the IL does produce the same access modes. It is also a step in the direction of fixing pr19844. llvm-svn: 209543
* Move the verbose asm option to be part of the options struct andEric Christopher2014-05-201-11/+3
| | | | | | set appropriately. llvm-svn: 209258
* Move the function and data section flags into the options struct andEric Christopher2014-05-201-15/+6
| | | | | | | | | | make the functions to set them non-static. Move and rename the llvm specific backend options to avoid conflicting with the clang option. Paired with a backend commit to update. llvm-svn: 209238
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-1/+1
| | | | llvm-svn: 209040
* Remove unused llvm namespace bool variable.Eric Christopher2014-05-151-1/+0
| | | | llvm-svn: 208931
* Move the TargetMachine MC options to MCTargetOptions. No functionalEric Christopher2014-05-151-4/+0
| | | | | | change. llvm-svn: 208832
* Remove MCUseCFI from TargetMachine.Rafael Espindola2014-05-121-1/+0
| | | | | | It was always true. llvm-svn: 208547
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-1/+1
| | | | llvm-svn: 207197
* Create MCTargetOptions.Evgeniy Stepanov2014-04-231-0/+3
| | | | | | | | | For now it contains a single flag, SanitizeAddress, which enables AddressSanitizer instrumentation of inline assembly. Patch by Yuri Gorshenin. llvm-svn: 206971
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
* Revert "Prevent alias from pointing to weak aliases."Rafael Espindola2014-03-261-1/+1
| | | | | | | | | This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
* move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola2014-02-191-0/+30
| | | | | | | | | | TargetLoweringBase is implemented in CodeGen, so before this patch we had a dependency fom Target to CodeGen. This would show up as a link failure of llvm-stress when building with -DBUILD_SHARED_LIBS=ON. This fixes pr18900. llvm-svn: 201711
* Remove support for not using .loc directives.Rafael Espindola2014-02-051-1/+0
| | | | | | Clang itself was not using this. The only way to access it was via llc. llvm-svn: 200862
* Revert r199871 and replace it with a simple check in the debug infoEric Christopher2014-01-281-1/+0
| | | | | | | | | code to see if we're emitting a function into a non-default text section. This is still a less-than-ideal solution, but more contained than r199871 to determine whether or not we're emitting code into an array of comdat sections. llvm-svn: 200269
* Add a variable to track whether or not we've used a unique section,Eric Christopher2014-01-231-0/+1
| | | | | | | | | | | | e.g. linkonce, to TargetMachine and set it when we've done so for ELF targets currently. This involved making TargetMachine non-const in a TLOF use and propagating that change around - I'm open to other ideas. This will be used in a future commit to handle emitting debug information with ranges. llvm-svn: 199871
* Add a RequireStructuredCFG Field to TargetMachine.Vincent Lejeune2013-12-071-0/+1
| | | | llvm-svn: 196634
OpenPOWER on IntegriCloud