summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [attrs] Split the late-revisit pattern for deducing norecurse inChandler Carruth2016-01-081-59/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a top-down manner into a true top-down or RPO pass over the call graph. There are specific patterns of function attributes, notably the norecurse attribute, which are most effectively propagated top-down because all they us caller information. Walk in RPO over the call graph SCCs takes the form of a module pass run immediately after the CGSCC pass managers postorder walk of the SCCs, trying again to deduce norerucrse for each singular SCC in the call graph. This removes a very legacy pass manager specific trick of using a lazy revisit list traversed during finalization of the CGSCC pass. There is no analogous finalization step in the new pass manager, and a lazy revisit list is just trying to produce an RPO iteration of the call graph. We can do that more directly if more expensively. It seems unlikely that this will be the expensive part of any compilation though as we never examine the function bodies here. Even in an LTO run over a very large module, this should be a reasonable fast set of operations over a reasonably small working set -- the function call graph itself. In the future, if this really is a compile time performance issue, we can look at building support for both post order and RPO traversals directly into a pass manager that builds and maintains the PO list of SCCs. Differential Revision: http://reviews.llvm.org/D15785 llvm-svn: 257163
* [attrs] Extract the pure inference of function attributes intoChandler Carruth2015-12-271-852/+1
| | | | | | | | | | | | | | | | | | | | | | | | | a standalone pass. There is no call graph or even interesting analysis for this part of function attributes -- it is literally inferring attributes based on the target library identification. As such, we can do it using a much simpler module pass that just walks the declarations. This can also happen much earlier in the pass pipeline which has benefits for any number of other passes. In the process, I've cleaned up one particular aspect of the logic which was necessary in order to separate the two passes cleanly. It now counts inferred attributes independently rather than just counting all the inferred attributes as one, and the counts are more clearly explained. The two test cases we had for this code path are both ... woefully inadequate and copies of each other. I've kept the superset test and updated it. We need more testing here, but I had to pick somewhere to stop fixing everything broken I saw here. Differential Revision: http://reviews.llvm.org/D15676 llvm-svn: 256466
* [attrs] Split off the forced attributes utility into its own pass thatChandler Carruth2015-12-271-66/+0
| | | | | | | | | | | | | | | is (by default) run much earlier than FuncitonAttrs proper. This allows forcing optnone or other widely impactful attributes. It is also a bit simpler as the force attribute behavior needs no specific iteration order. I've added the pass into the default module pass pipeline and LTO pass pipeline which mirrors where function attrs itself was being run. Differential Revision: http://reviews.llvm.org/D15668 llvm-svn: 256465
* Revert "[FunctionAttrs] Remove redundant assignment."Tilmann Scheller2015-11-201-0/+2
| | | | | | | | | | This reverts r253661. Turns out that the assignment is not redundant (despite the Clang static analyzer claiming the opposite). The variable is being used by the lambda function AddUsersToWorklistIfCapturing(). llvm-svn: 253696
* [FunctionAttrs] Remove redundant assignment.Tilmann Scheller2015-11-201-2/+0
| | | | | | Identified by the Clang static analyzer. llvm-svn: 253661
* [FunctionAttrs] Provide a mechanism for adding function attributes from the ↵James Molloy2015-11-191-0/+67
| | | | | | | | | | | | command line This provides a way to force a function to have certain attributes from the command line. This can be useful when debugging or doing workload exploration, where manually editing IR is tedious or not possible (due to build systems etc). The syntax is -force-attribute=function_name:attribute_name All function attributes are parsed except alignstack as it requires an argument. llvm-svn: 253550
* Vector of pointers in function attributes calculationElena Demikhovsky2015-11-171-1/+1
| | | | | | | | | While setting function attributes we check all instructions that may access memory. For a call instruction we check all arguments. The special check is required for pointers. I added vector-of-pointers to the call arguments types that should be checked. Differential Revision: http://reviews.llvm.org/D14693 llvm-svn: 253363
* Revert "Revert "[FunctionAttrs] Identify norecurse functions""James Molloy2015-11-121-1/+78
| | | | | | This reapplies this patch, with test fixes. llvm-svn: 252871
* Revert "[FunctionAttrs] Identify norecurse functions"James Molloy2015-11-121-78/+1
| | | | | | This reverts commit r252862. This introduced test failures and I'm reverting while I investigate how this happened. llvm-svn: 252863
* [FunctionAttrs] Identify norecurse functionsJames Molloy2015-11-121-1/+78
| | | | | | | | | | | | | A function can be marked as norecurse if: * The SCC to which it belongs has cardinality 1; and either a) It does not call any non-norecurse function. This includes self-recursion; or b) It only has one callsite and the function that callsite is within is marked norecurse. a) is best propagated bottom-up and b) is best propagated top-down. We build up the norecurse attributes bottom-up using the existing SCC pass, and mark functions with no obvious recursion (but not provably norecurse) to sweep later, top-down. llvm-svn: 252862
* Unbreak the buildSanjoy Das2015-11-071-1/+1
| | | | | | | My code clashed with some ilist iterator changes upstream. Fix by adding an explicit "&*" coercion. llvm-svn: 252392
* [FunctionAttrs] Add comment and clarify assertion message; NFCSanjoy Das2015-11-071-1/+6
| | | | llvm-svn: 252389
* [FunctionAttrs] Add handling for operand bundlesSanjoy Das2015-11-071-4/+31
| | | | | | | | | | | | | | Summary: Teach the FunctionAttrs to do the right thing for IR with operand bundles. Reviewers: reames, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14408 llvm-svn: 252387
* [FunctionAttrs] Fix an iterator wraparound bugSanjoy Das2015-11-071-18/+19
| | | | | | | | | | | | | | | | | | | Summary: This change fixes an iterator wraparound bug in `determinePointerReadAttrs`. Ideally, ++'ing off the `end()` of an iplist should result in a failed assert, but currently iplist seems to silently wrap to the head of the list on `end()++`. This is why the bad behavior is difficult to demonstrate. Reviewers: chandlerc, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14350 llvm-svn: 252386
* ADT: Remove last implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-071-1/+1
| | | | | | | | | | Some implicit ilist iterator conversions have crept back into Analysis, Transforms, Hexagon, and llvm-stress. This removes them. I'll commit a patch immediately after this to disallow them (in a separate patch so that it's easy to revert if necessary). llvm-svn: 252371
* [FunctionAttrs] Remove a loop, NFC refactorSanjoy Das2015-11-051-16/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: Remove the loop over the uses of the CallSite in ArgumentUsesTracker. Since we have the `Use *` for actual argument operand, we can just use pointer subtraction. The time complexity remains the same though (except for a vararg argument) -- `std::advance` is O(UseIndex) for the ArgumentList iterator. The real motivation is to make a later change adding support for operand bundles simpler. Reviewers: reames, chandlerc, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14363 llvm-svn: 252141
* [FunctionAttrs] Inline the prototype attribute inference to an existingChandler Carruth2015-10-311-21/+6
| | | | | | | | loop over the SCC. The separate function wasn't really adding much, NFC. llvm-svn: 251728
* [FunctionAttrs] Separate another chunk of the logic for functionattrsChandler Carruth2015-10-301-10/+16
| | | | | | | | | | | from its pass harness by providing a lambda to query for AA results. This allows the legacy pass to easily provide a lambda that uses the special helpers to construct function AA results from a legacy CGSCC pass. With the new pass manager (the next patch) the lambda just directly wraps the intuitive query API. llvm-svn: 251715
* [FunctionAttrs] Provide a single SCC node set to all of theChandler Carruth2015-10-291-91/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transformations in FunctionAttrs rather than building a new one each time. This isn't trivial because there are different heuristics from different passes for exactly what set they want. The primary difference is whether an *overridable* function completely disables the synthesis of attributes. I've modeled this by directly testing for overridable, and using the common set that excludes external and opt-none functions. This does cause some changes by disabling more optimizations in the face of opt-none. Specifically, we were still optimizing *calls* to opt-none functions based on their attributes, just not the bodies. It seems better to be conservative on both fronts given the intended semanticas here (best effort to not assume or disturb anything). I've not tried to test this change as it seems complex, brittle, and not important to the implicit contract of opt-none. Instead, it seems more like a choice that should be dictated by the simplified implementation and the change to be acceptable differences within the space of opt-none. A big benefit here is that these transformations no longer rely on the legacy pass manager's SCC types, they just work on generic sets of function pointers. This will make it easy to re-use their logic in the new pass manager. I've also made the transforms static functions instead of members where trivial while I was touching the signatures. llvm-svn: 251640
* [function-attrs] Refactor code to handle shorter code with early exits.Chandler Carruth2015-10-271-31/+37
| | | | | | | | | | | No functionality changed here, but the indentation is substantially reduced and IMO the code is much easier to read. I've also added some helpful comments. This is just a clean-up I wrote while studying the code, and that has been in my backlog for a while. llvm-svn: 251381
* IPO: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-6/+6
| | | | llvm-svn: 250187
* [FunctionAttrs] Extract a helper function for the core logic used toChandler Carruth2015-09-211-90/+117
| | | | | | | | evaluate whether 'readonly' or 'readnone' apply to a given function. This both reduces indentation and will make it easy to share the logic with a new pass manager implementation. llvm-svn: 248181
* [FunctionAttrs] Move the malloc-like test to a static helper functionChandler Carruth2015-09-131-4/+3
| | | | | | | that could be used from a new pass manager. This one makes particular sense as a static helper as it doesn't even need TLI. llvm-svn: 247525
* [FunctionAttrs] Factor the logic to test for a known non-null return outChandler Carruth2015-09-131-7/+10
| | | | | | | | | | of a method and into a re-usable static helper. We can potentially use this function from the implementation of a new pass manager oriented version of the pass. Also add some better documentation of exactly what the semantic model of this routine is (it isn't trivial) and use a more modern naming convention for it. llvm-svn: 247524
* [FunctionAttrs] Make the per-function attribute inference a boringChandler Carruth2015-09-131-4/+3
| | | | | | | | | static function rather than a method. It just needed access to TargetLibraryInfo, and this way it can be easily reused between the current FunctionAttrs implementation and any port for the new pass manager. llvm-svn: 247522
* [FunctionAttrs] Collect utility functions as static helpers rather thanChandler Carruth2015-09-131-57/+52
| | | | | | | | methods. They don't need anything from the class anyways. Also, collect the declarations into the private section of the pass. llvm-svn: 247521
* Clean up doxygen comments in FunctionAttrs, promoting some non-doxygenChandler Carruth2015-09-131-34/+21
| | | | | | | | comments, deleting duplicate comments, moving comments to consistently live on the definition since these are all really internal routines, etc. NFC. llvm-svn: 247520
* Do some spring cleaning on FunctionAttrs.cpp with clang-format prior toChandler Carruth2015-09-131-340/+299
| | | | | | other refactorings and cleanups here. llvm-svn: 247519
* [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatibleChandler Carruth2015-09-091-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
* Fix Windows build by including raw_ostream.hHans Wennborg2015-08-311-0/+1
| | | | llvm-svn: 246486
* [FunctionAttr] Infer nonnull attributes on returnsPhilip Reames2015-08-311-0/+148
| | | | | | | | Teach FunctionAttr to infer the nonnull attribute on return values of functions which never return a potentially null value. This is done both via a conservative local analysis for the function itself and a optimistic per-SCC analysis. If no function in the SCC returns anything which could be null (other than values from other functions in the SCC), we can conclude no function returned a null pointer. Even if some function within the SCC returns a null pointer, we may be able to locally conclude that some don't. Differential Revision: http://reviews.llvm.org/D9688 llvm-svn: 246476
* Remove unused variable. NFC.Diego Novillo2015-07-241-1/+0
| | | | llvm-svn: 243145
* Remove the user-count threshold when analyzing read attributesJingyue Wu2015-07-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This threshold limited FunctionAttrs ability to prove arguments to be read-only. In NVPTX, a specialized instruction ld.global.nc can be used to load memory with non-coherent texture cache. We notice that in SHOC [1] benchmark, some function arguments are not marked with readonly because FunctionAttrs reaches a hardcoded threshold when analysis uses. Removing this threshold won't cause significant regression in compilation time, because the worst-case time complexity of the algorithm is still O(# of instructions) for each parameter. Patched by Xuetian Weng. [1] https://github.com/vetter/shoc Reviewers: nlewycky, jingyue, nicholas Subscribers: nicholas, test, llvm-commits Differential Revision: http://reviews.llvm.org/D11311 llvm-svn: 243141
* [PM/AA] Extract the ModRef enums from the AliasAnalysis class inChandler Carruth2015-07-221-7/+7
| | | | | | | | | | | | | | | | | | | | | | | preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-3/+3
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-3/+3
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* [PM/AA] Remove the UnknownSize static member from AliasAnalysis.Chandler Carruth2015-06-171-1/+1
| | | | | | | | This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-171-5/+4
| | | | | | | | | | | | that it is its own entity in the form of MemoryLocation, and update all the callers. This is an entirely mechanical change. References to "Location" within AA subclases become "MemoryLocation", and elsewhere "AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps out-of-tree folks update. llvm-svn: 239885
* [PM/AA] Start refactoring AliasAnalysis to remove the analysis group andChandler Carruth2015-06-041-3/+3
| | | | | | | | | | | | | | | | | | | | | port it to the new pass manager. All this does is extract the inner "location" class used by AA into its own full fledged type. This seems *much* cleaner as MemoryDependence and soon MemorySSA also use this heavily, and it doesn't make much sense being inside the AA infrastructure. This will also make it much easier to break apart the AA infrastructure into something that stands on its own rather than using the analysis group design. There are a few places where this makes APIs not make sense -- they were taking an AliasAnalysis pointer just to build locations. I'll try to clean those up in follow-up commits. Differential Revision: http://reviews.llvm.org/D10228 llvm-svn: 239003
* Remove conflicting attributes before adding deduced readonly/readnoneBjorn Steinbrink2015-05-251-1/+5
| | | | | | | | | | | | | | | | Summary: In case of functions that have a pointer argument and only pass it to each other, the function attributes pass deduces that the pointer should get the readnone attribute, but fails to remove a readonly attribute that may already have been present. Reviewers: nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9995 llvm-svn: 238152
* Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.Pete Cooper2015-05-121-2/+2
| | | | | | | | We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it. Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB. llvm-svn: 237169
* [PM] Separate the TargetLibraryInfo object from the immutable pass.Chandler Carruth2015-01-151-3/+3
| | | | | | | | | | | | | | 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
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-2/+2
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* [optnone] Make the optnone attribute effective at suppressing functionChandler Carruth2014-08-131-7/+13
| | | | | | | | | | | | | attribute and function argument attribute synthesizing and propagating. As with the other uses of this attribute, the goal remains a best-effort (no guarantees) attempt to not optimize the function or assume things about the function when optimizing. This is particularly useful for compiler testing, bisecting miscompiles, triaging things, etc. I was hitting specific issues using optnone to isolate test code from a test driver for my fuzz testing, and this is one step of fixing that. llvm-svn: 215538
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-2/+4
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* When analyzing params/args for readnone/readonly, don't forget to consider ↵Nick Lewycky2014-05-301-1/+18
| | | | | | that a pointer argument may be passed through a callsite to the return, and that we may need to analyze it. Fixes a bug reported on llvm-dev: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073098.html llvm-svn: 209870
* SCC: Change clients to use const, NFCDuncan P. N. Exon Smith2014-04-251-7/+6
| | | | | | | | | | It's fishy to be changing the `std::vector<>` owned by the iterator, and no one actual does it, so I'm going to remove the ability in a subsequent commit. First, update the users. <rdar://problem/14292693> llvm-svn: 207252
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-6/+6
| | | | llvm-svn: 207196
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | | | | | | definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844
OpenPOWER on IntegriCloud