summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Target.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [PM] Rework how the TargetLibraryInfo pass integrates with the new passChandler Carruth2015-01-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
* [PM] Separate the TargetLibraryInfo object from the immutable pass.Chandler Carruth2015-01-151-2/+2
| | | | | | | | | | | | | | The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-1/+1
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* [un]wrap extracted from lib/Target/Target[MachineC].cpp, ↵Artyom Skrobov2014-05-131-8/+0
| | | | | | lib/ExecutionEngine/ExecutionEngineBindings.cpp into include/llvm/IR/DataLayout.h llvm-svn: 208680
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-251-0/+2
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-2/+2
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Remove the 's' DataLayout specificationRafael Espindola2014-01-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | During the years there have been some attempts at figuring out how to align byval arguments. A look at the commit log suggests that they were * Use the ABI alignment. * When that was not sufficient for x86-64, I added the 's' specification to DataLayout. * When that was not sufficient Evan added the virtual getByValTypeAlignment. * When even that was not sufficient, we just got the FE to add the alignment to the byval. This patch is just a simple cleanup that removes my first attempt at fixing the problem. I also added an AArch64 implementation of getByValTypeAlignment to make sure this patch is a nop. I also left the 's' parsing for backward compatibility. I will send a short email to llvmdev about the change for anyone maintaining an out of tree target. llvm-svn: 198287
* llvm-c: Add LLVMIntPtrType{,ForAS}InContextAnders Waldenborg2013-10-171-0/+8
| | | | | | | | | | | | All of the Core API functions have versions which accept explicit context, in addition to ones which work on global context. This commit adds functions which accept explicit context to the Target API for consistency. Patch by Peter Zotov Differential Revision: http://llvm-reviews.chandlerc.com/D1912 llvm-svn: 192913
* This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo2013-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. llvm-svn: 180881
* Move C++ code out of the C headers and into either C++ headersEric Christopher2013-04-221-0/+18
| | | | | | | or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. llvm-svn: 180063
* Convert the TargetTransformInfo from an immutable pass with dynamicChandler Carruth2013-01-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | interfaces which could be extracted from it, and must be provided on construction, to a chained analysis group. The end goal here is that TTI works much like AA -- there is a baseline "no-op" and target independent pass which is in the group, and each target can expose a target-specific pass in the group. These passes will naturally chain allowing each target-specific pass to delegate to the generic pass as needed. In particular, this will allow a much simpler interface for passes that would like to use TTI -- they can have a hard dependency on TTI and it will just be satisfied by the stub implementation when that is all that is available. This patch is a WIP however. In particular, the "stub" pass is actually the one and only pass, and everything there is implemented by delegating to the target-provided interfaces. As a consequence the tools still have to explicitly construct the pass. Switching targets to provide custom passes and sinking the stub behavior into the NoTTI pass is the next step. llvm-svn: 171621
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 171366
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+2
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Revert the series of commits starting with r166578 which introduced theChandler Carruth2012-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getIntPtrType support for multiple address spaces via a pointer type, and also introduced a crasher bug in the constant folder reported in PR14233. These commits also contained several problems that should really be addressed before they are re-committed. I have avoided reverting various cleanups to the DataLayout APIs that are reasonable to have moving forward in order to reduce the amount of churn, and minimize the number of commits that were reverted. I've also manually updated merge conflicts and manually arranged for the getIntPtrType function to stay in DataLayout and to be defined in a plausible way after this revert. Thanks to Duncan for working through this exact strategy with me, and Nick Lewycky for tracking down the really annoying crasher this triggered. (Test case to follow in its own commit.) After discussing with Duncan extensively, and based on a note from Micah, I'm going to continue to back out some more of the more problematic patches in this series in order to ensure we go into the LLVM 3.2 branch with a reasonable story here. I'll send a note to llvmdev explaining what's going on and why. Summary of reverted revisions: r166634: Fix a compiler warning with an unused variable. r166607: Add some cleanup to the DataLayout changes requested by Chandler. r166596: Revert "Back out r166591, not sure why this made it through since I cancelled the command. Bleh, sorry about this! r166591: Delete a directory that wasn't supposed to be checked in yet. r166578: Add in support for getIntPtrType to get the pointer type based on the address space. llvm-svn: 167221
* Add in support for getIntPtrType to get the pointer type based on the ↵Micah Villmow2012-10-241-1/+1
| | | | | | | | | address space. This checkin also adds in some tests that utilize these paths and updates some of the clients. llvm-svn: 166578
* Reapply the TargerTransformInfo changes, minus the changes to LSR and ↵Nadav Rotem2012-10-181-0/+1
| | | | | | Lowerinvoke. llvm-svn: 166248
* Temporarily revert the TargetTransform changes.Bob Wilson2012-10-181-1/+0
| | | | | | | | | | | 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 llvm-svn: 166168
* Resubmit the changes to llvm core to update the functions to support ↵Micah Villmow2012-10-151-1/+9
| | | | | | different pointer sizes on a per address space basis. llvm-svn: 165941
* Revert 165732 for further review.Micah Villmow2012-10-111-9/+1
| | | | llvm-svn: 165747
* Add in the first iteration of support for llvm/clang/lldb to allow variable ↵Micah Villmow2012-10-111-1/+9
| | | | | | per address space pointer sizes to be optimized correctly. llvm-svn: 165726
* Add a new interface to allow IR-level passes to access codegen-specific ↵Nadav Rotem2012-10-101-0/+1
| | | | | | information. llvm-svn: 165665
* Move TargetData to DataLayout.Micah Villmow2012-10-081-3/+3
| | | | llvm-svn: 165402
* Implement TargetData with the DataLayout class, this will allow LLVM ↵Micah Villmow2012-10-051-1/+1
| | | | | | projects to transition to DataLayout without loosing functionality. llvm-svn: 165318
* Add LLVMAddTargetLibraryInfo to the C API.Rafael Espindola2011-07-251-0/+6
| | | | llvm-svn: 135975
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-2/+2
| | | | llvm-svn: 135375
* remove the InvalidateStructLayoutInfo API, which is dead and unnecessary nowChris Lattner2011-07-151-4/+0
| | | | | | that type refinement is toast. llvm-svn: 135245
* introduce a new TargetLibraryInfo pass, which transformations can use toChris Lattner2011-02-181-0/+1
| | | | | | | | query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
* Improve comment.Owen Anderson2010-10-071-1/+1
| | | | llvm-svn: 115966
* Add initialization routines for Target.Owen Anderson2010-10-071-2/+12
| | | | llvm-svn: 115957
* "In order to ease automatic bindings generation, it would be helpful if ↵Chris Lattner2010-01-091-1/+1
| | | | | | | | boolean values were distinguishable from integers. The attached patch introduces "typedef int LLVMBool;", and uses LLVMBool instead of int throughout the C API, wherever a boolean value is called for." Patch by James Y Knight! llvm-svn: 93079
* move debug info stuff out of line, allowing two #includesChris Lattner2009-12-281-0/+1
| | | | | | to go away from IRBuilder.h llvm-svn: 92230
* Push LLVMContexts through the IntegerType APIs.Owen Anderson2009-08-131-1/+1
| | | | llvm-svn: 78948
* Rename PaddedSize to AllocSize, in the hope that thisDuncan Sands2009-05-091-1/+1
| | | | | | | will make it more obvious what it represents, and stop it being confused with the StoreSize. llvm-svn: 71349
* Rename getABITypeSize to getTypePaddedSize, asDuncan Sands2009-01-121-1/+1
| | | | | | suggested by Chris. llvm-svn: 62099
* strdup needs <cstring>. This fixes a build error with g++-4.3.Torok Edwin2008-04-041-0/+1
| | | | llvm-svn: 49218
* C and Objective Caml bindings for the TargetData class.Gordon Henriksen2008-03-161-0/+93
llvm-svn: 48422
OpenPOWER on IntegriCloud