aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/LazyCallGraph.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-03-28[llvm] Use range constructors of *Set (NFC) (#133549)Kazu Hirata1-1/+1
2025-02-14Revert "[Coroutines][LazyCallGraph] addSplitRefRecursiveFunctions allows ↵Arthur Eubanks1-4/+2
spurious ref edges between new functions." (#127285) Reverts llvm/llvm-project#116285 Breaks expensive checks build, e.g. https://lab.llvm.org/buildbot/#/builders/16/builds/13821
2025-02-14[Coroutines][LazyCallGraph] addSplitRefRecursiveFunctions allows spurious ↵Tyler Nowicki1-2/+4
ref edges between new functions. (#116285) The addSplitRefRecursiveFunctions LazyCallGraph helper should not require a reference between every new function. Spurious ref edges between the new functions are allowed and the new function are considered to be a RefSCC. This change clarifies that this is the case in the method's description and its DEBUG mode verifier.
2024-10-24[llvm] Support llvm::Any across shared libraries on windows (#108051)Thomas Fransham1-0/+2
This is part of the effort to support for enabling plugins on windows by adding better support for building llvm as a DLL. The export macros used here were added in #96630 Since shared library symbols aren't deduplicated across multiple libraries on windows like Linux we have to manually explicitly import and export `Any::TypeId` template instantiations for the uses of `llvm::Any` in the LLVM codebase to support LLVM Windows shared library builds. This change ensures that external code, including LLVM's own tests, can use PassManager callbacks when LLVM is built as a DLL. I also removed the only use of llvm::Any for LoopNest that only existed in debug code and there also doesn't seem to be any code creating `Any<LoopNest>`
2024-06-11[CGSCC] Fix compile time blowup with large RefSCCs (#94815)Arthur Eubanks1-59/+64
In some modules, e.g. Kotlin-generated IR, we end up with a huge RefSCC and the call graph updates done as a result of the inliner take a long time. This is due to RefSCC::removeInternalRefEdges() getting called many times, each time removing one function from the RefSCC, but each call to removeInternalRefEdges() is proportional to the size of the RefSCC. There are two places that call removeInternalRefEdges(), in updateCGAndAnalysisManagerForPass() and LazyCallGraph::removeDeadFunction(). 1) Since LazyCallGraph can deal with spurious (edges that exist in the graph but not in the IR) ref edges, we can simply not call removeInternalRefEdges() in updateCGAndAnalysisManagerForPass(). 2) LazyCallGraph::removeDeadFunction() still ends up taking the brunt of compile time with the above change for the original reason. So instead we batch all the dead function removals so we can call removeInternalRefEdges() just once. This requires some changes to callers of removeDeadFunction() to not actually erase the function from the module, but defer it to when we batch delete dead functions at the end of the CGSCC run, leaving the function body as "unreachable" in the meantime. We still need to ensure that call edges are accurate. I had also tried deleting dead functions after visiting a RefSCC, but deleting them all at once at the end was simpler. Many test changes are due to not performing unnecessary revisits of an SCC (the CGSCC infrastructure deems ref edge refinements as unimportant when it comes to revisiting SCCs, although that seems to not be consistently true given these changes) because we don't remove some ref edges. Specifically for devirt-invalidated.ll this seems to expose an inlining order issue with the inliner. Probably unimportant for this type of intentionally weird call graph. Compile time: https://llvm-compile-time-tracker.com/compare.php?from=6f2c61071c274a1b5e212e6ad4114641ec7c7fc3&to=b08c90d05e290dd065755ea776ceaf1420680224&stat=instructions:u
2024-06-07[CGSCC] Verify that call graph is valid after iteration (#94692)Arthur Eubanks1-0/+8
Only in expensive checks, to match other LazyCallGraph verification. Is helpful for verifying LazyCallGraph updates. Many issues only surface when we reuse the LazyCallGraph.
2024-06-04[LazyCallGraph] Assert in removeDeadFunction() that NodeMap contains functionArthur Eubanks1-3/+1
The function should always be known to LazyCallGraph
2023-01-05Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ partserge-sans-paille1-1/+1
Use deduction guides instead of helper functions. The only non-automatic changes have been: 1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*)) 2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase. 3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated. 4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that). Per reviewers' comment, some useless makeArrayRef have been removed in the process. This is a follow-up to https://reviews.llvm.org/D140896 that introduced the deduction guides. Differential Revision: https://reviews.llvm.org/D140955
2022-09-22[LazyCallGraph] Handle spurious ref edges when deleting a dead functionArthur Eubanks1-8/+28
Spurious ref edges are ref edges that still exist in the call graph even though the corresponding IR reference no longer exists. This can cause issues when deleting a dead function which has a spurious ref edge pointed at it because currently we expect the dead function's RefSCC to be trivial. In the case that the dead function's RefSCC is not trivial, remove all ref edges from other nodes in the RefSCC to it. Removing a ref edge can result in splitting RefSCCs. There's actually no reason to revisit those RefSCCs because currently we only run passes on SCCs, and we've already added all SCCs in the RefSCC to the worklist. (as opposed to removing the ref edge in updateCGAndAnalysisManagerForPass() which can modify the call graph of SCCs we have not visited yet). We also don't expect that RefSCC refinement will allow us to glean any more information for optimization use. Also, doing so would drastically increase the complexity of LazyCallGraph::removeDeadFunction(), requiring us to return a list of invalidated RefSCCs and new RefSCCs to add to the worklist. Fixes #56503 Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D133907
2022-08-30[LazyCallGraph] Reformat the code in accordance with the code style. NFCPavel Samolysov1-74/+55
Also, some local variables were renamed in accordance with the code style as well as `std::tie` occurrences and `.first`/`.second` member uses were replaced with structure bindings. Differential Revision: https://reviews.llvm.org/D132806
2022-08-27[LazyCallGraph] Update libcall list when replacing a libcall node's functionArthur Eubanks1-0/+6
Otherwise when we visit all libcalls in updateCGAndAnalysisManagerForPass(), the old libcall is dead and doesn't have a node. We treat libcalls conservatively in LazyCallGraph because any function may introduce calls to them out of thin air. It is weird to change the signature of a libcall since introducing calls to the libcall with a different signature may break, but other passes like deadargelim already do it, so let's preserve this behavior for now. Fixes an issue found in D128830. Reviewed By: psamolysov Differential Revision: https://reviews.llvm.org/D132764
2022-03-12Add missing include under EXPENSIVE_CHECKSserge-sans-paille1-0/+4
2022-03-12Cleanup includes: DebugInfo & CodeGenserge-sans-paille1-1/+0
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121332
2022-03-03Revert "Add missing include under EXPENSIVE_CHECK"serge-sans-paille1-4/+0
This reverts commit eeaca53df7a030862bd1160950a6264aeb605cc6. It's a duplicate of https://reviews.llvm.org/rG50874a188b94a25827963956887b878d3701509a
2022-03-01Add missing include under EXPENSIVE_CHECKserge-sans-paille1-0/+4
This is a followup to 344f8ec3048b6eeef94569800acb012f794ad372 It should fix https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/21961/console
2022-03-01Fix -DLLVM_ENABLE_EXPENSIVE_CHECKS=on build after D120659Fangrui Song1-0/+1
2022-03-01Cleanup includes: LLVMAnalysisserge-sans-paille1-3/+1
Number of lines output by preprocessor: before: 1065940348 after: 1065307662 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120659
2022-01-13[Inliner] Don't removeDeadConstantUsers() when checking if a function is deadArthur Eubanks1-1/+1
If a function has many uses, this can take a good chunk of compile times. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117236
2022-01-11[NFC][LazyCallGraph] Remove check in removeDeadFunction() if graph is emptyArthur Eubanks1-7/+0
If we're in removeDeadFunction(), we should have already constructed the call graph. Differential Revision: https://reviews.llvm.org/D115676
2022-01-07[LazyCallGraph] Ignore empty RefSCCs rather than shift RefSCCs when removing ↵Arthur Eubanks1-8/+2
dead functions This is in preparation for D115545 which attempts to delete discardable functions if they are unused. With that change, shifting RefSCCs becomes noticeable in compile time. This change makes the LCG update negligible again. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D116776
2021-11-01[LazyCallGraph] Skip blockaddressesArthur Eubanks1-21/+3
blockaddresses do not participate in the call graph since the only instructions that use them must all return to someplace within the current function. And passes cannot retrieve a function address from a blockaddress. This was suggested by efriedma in D58260. Fixes PR50881. Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D112178
2021-10-20[NFC] De-template LazyCallGraph::visitReferences() and move into .cpp fileArthur Eubanks1-0/+41
This makes changing it and recompiling it much faster.
2021-10-11[LCG] Don't skip invalidation of LazyCallGraph if CFG analyses are preservedArthur Eubanks1-2/+1
The CFG being changed and the overall call graph are not related, we can introduce/remove calls without changing the CFG. Resolves one of the issues in PR51946. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D111275
2021-06-19Allow building for release with EXPENSIVE_CHECKSTomas Matheson1-2/+2
D97225 moved LazyCallGraph verify() calls behind EXPENSIVE_CHECKS, but verity() is defined for debug builds only so this had the unintended effect of breaking release builds with EXPENSIVE_CHECKS. Fix by enabling verify() for both debug and EXPENSIVE_CHECKS. Differential Revision: https://reviews.llvm.org/D104514
2021-02-22Only verify LazyCallGraph under expensive checksArthur Eubanks1-48/+25
These verify calls are causing a lot of slowdown on some files, up to 8x. The LazyCallGraph infra has been tested a lot over the years, so I'm fairly confident that we don't always need to run the verifys. These verifies took >90% of total time in one of the compilations I looked at. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D97225
2021-01-14[llvm] Use llvm::drop_begin (NFC)Kazu Hirata1-1/+1
2021-01-06Fix non-assert builds after D93828Arthur Eubanks1-1/+1
2021-01-06[CGSCC][Coroutine][NewPM] Properly support function splitting/outliningArthur Eubanks1-4/+256
Previously when trying to support CoroSplit's function splitting, we added in a hack that simply added the new function's node into the original function's SCC (https://reviews.llvm.org/D87798). This is incorrect since it might be in its own SCC. Now, more similar to the previous design, we have callers explicitly notify the LazyCallGraph that a function has been split out from another one. In order to properly support CoroSplit, there are two ways functions can be split out. One is the normal expected "outlining" of one function into a new one. The new function may only contain references to other functions that the original did. The original function must reference the new function. The new function may reference the original function, which can result in the new function being in the same SCC as the original function. The weird case is when the original function indirectly references the new function, but the new function directly calls the original function, resulting in the new SCC being a parent of the original function's SCC. This form of function splitting works with CoroSplit's Switch ABI. The second way of splitting is more specific to CoroSplit. CoroSplit's Retcon and Async ABIs split the original function into multiple functions that all reference each other and are referenced by the original function. In order to keep the LazyCallGraph in a valid state, all new functions must be processed together, else some nodes won't be populated. To keep things simple, this only supports the case where all new edges are ref edges, and every new function references every other new function. There can be a reference back from any new function to the original function, putting all functions in the same RefSCC. This also adds asserts that all nodes in a (Ref)SCC can reach all other nodes to prevent future incorrect hacks. The original hacks in https://reviews.llvm.org/D87798 are no longer necessary since all new functions should have been registered before calling updateCGAndAnalysisManagerForPass. This fixes all coroutine tests when opt's -enable-new-pm is true by default. This also fixes PR48190, which was likely due to the previous hack breaking SCC invariants. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D93828
2021-01-04Remove RefSCC::handleTrivialEdgeInsertionXun Li1-23/+0
This function no longer does anything useful. It probably did something originally but latter changes removed them and didn't clean up this function. The checks are already done in the callers as well. Differential Revision: https://reviews.llvm.org/D94055
2020-11-02[LazyCallGraph] Build SCCs of the reference graph in orderFangrui Song1-4/+1
``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-09-23[NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPassArthur Eubanks1-22/+3
This seems to fit the CGSCC updates model better than calling addNewFunctionInto{Ref,}SCC() on newly created/outlined functions. Now addNewFunctionInto{Ref,}SCC() are no longer necessary. However, this doesn't work on newly outlined functions that aren't referenced by the original function. e.g. if a() was outlined into b() and c(), but c() is only referenced by b() and not by a(), this will trigger an assert. This also fixes an issue I was seeing with newly created functions not having passes run on them. Ran check-llvm with expensive checks. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D87798
2020-09-15[CGSCC][NewPM] Fix adding mutually recursive new functionsArthur Eubanks1-2/+0
When adding a new function via addNewFunctionIntoRefSCC(), it creates a new node and immediately populates the edges. Since populateSlow() calls G->get() on all referenced functions, it will create a node (but not populate it) for functions that haven't yet been added. If we add two mutually recursive functions, the assert that the node should never have been created will fire when the second function is added. So here we remove that assert since the node may have already been created (but not yet populated). createNode() is only called from addNewFunctionInto{,Ref}SCC(). https://bugs.llvm.org/show_bug.cgi?id=47502 Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D87623
2020-04-14[llvm][NFC][CallSite] Remove Implementation uses of CallSiteMircea Trofin1-3/+2
Reviewers: dblaikie, davidxl, craig.topper Subscribers: arsenm, dschuff, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78142
2020-02-18[LazyCallGraph] Fix ambiguous index valueBrian Gesiak1-1/+2
After having committed https://reviews.llvm.org/D72226, 2 buildbots running GCC 5.4.0 began failing. The cause was the order in which those compilers evaluated the left- and right-hand sides of the expression `RC.SCCIndices[C] = RC.SCCIndices.size();`. This commit splits the expression into multiple statements to avoid ambiguity, and adds a test case that exercises the code that caused the test failures on those older compilers (which was originally included in the reviewed patch, https://reviews.llvm.org/D72226).
2020-02-17Re-land "Add LazyCallGraph API to add function to RefSCC"Brian Gesiak1-6/+26
This re-commits https://reviews.llvm.org/D70927, which I reverted in https://reviews.llvm.org/rG28213680b2a7d1fdeea16aa3f3a368879472c72a due to a buildbot error: http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251 I no longer include a test case that appears to crash when built with the buildbot's compiler, GCC 5.4.0.
2020-02-17Revert "Add LazyCallGraph API to add function to RefSCC"Brian Gesiak1-26/+6
This reverts commit https://reviews.llvm.org/rG449a13509190b1c57e5fcf5cd7e8f0f647f564b4, due to buildbot failures such as http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13251.
2020-02-17Add LazyCallGraph API to add function to RefSCCBrian Gesiak1-6/+26
Summary: Depends on https://reviews.llvm.org/D70927. `LazyCallGraph::addNewFunctionIntoSCC` allows users to insert a new function node into a call graph, into a specific, existing SCC. Extend this interface such that functions can be added even when they do not belong in any existing SCC, but instead in a new SCC within an existing RefSCC. The ability to insert new functions as part of a RefSCC is necessary for outlined functions that do not form a strongly connected cycle with the function they are outlined from. An example of such a function would be the coroutine funclets 'f.resume', etc., which are outlined from a coroutine 'f'. Coroutine 'f' only references the funclets' addresses, it does not call them directly. Reviewers: jdoerfert, chandlerc, wenlei, hfinkel Reviewed By: jdoerfert Subscribers: hfinkel, JonChesterfield, mehdi_amini, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72226
2020-02-08Introduce a CallGraph updater helper classJohannes Doerfert1-0/+9
The CallGraphUpdater is a helper that simplifies the process of updating the call graph, both old and new style, while running an CGSCC pass. The uses are contained in different commits, e.g. D70767. More functionality is added as we need it. Reviewed By: modocache, hfinkel Differential Revision: https://reviews.llvm.org/D70927
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-2/+3
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-17[LazyCallGraph] Add invalidate method.Alina Sbirlea1-0/+9
Summary: Add invalidate method in LazyCallGraph. Reviewers: chandlerc, silvas Subscribers: hiraditya, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72817
2020-01-16[VectorUtils] Rework the Vector Function Database (VFDatabase).Francesco Petrogalli1-2/+6
Summary: This commits is a rework of the patch in https://reviews.llvm.org/D67572. The rework was requested to prevent out-of-tree performance regression when vectorizing out-of-tree IR intrinsics. The vectorization of such intrinsics is enquired via the static function `isTLIScalarize`. For detail see the discussion in https://reviews.llvm.org/D67572. Reviewers: uabelho, fhahn, sdesmalen Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72734
2019-12-13Revert "[VectorUtils] Introduce the Vector Function Database (VFDatabase)."Francesco Petrogalli1-6/+2
This reverts commit 0be81968a283fd4161cb9ac9748d5ed200926292. The VFDatabase needs some rework to be able to handle vectorization and subsequent scalarization of intrinsics in out-of-tree versions of the compiler. For more details, see the discussion in https://reviews.llvm.org/D67572.
2019-12-10[VectorUtils] Introduce the Vector Function Database (VFDatabase).Francesco Petrogalli1-2/+6
This patch introduced the VFDatabase, the framework proposed in http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html. [*] In this patch the VFDatabase is used to bridge the TargetLibraryInfo (TLI) calls that were previously used to query for the availability of vector counterparts of scalar functions. The VFISAKind field `ISA` of VFShape have been moved into into VFInfo, under the assumption that different vector ISAs may provide the same vector signature. At the moment, the vectorizer accepts any of the available ISAs as long as the signature provided by the VFDatabase matches the one expected in the vectorization process. For example, when targeting AVX or AVX2, which both have 256-bit registers, the IR signature of the two vector functions associated to the two ISAs is the same. The `getVectorizedFunction` method at the moment returns the first available match. We will need to add more heuristics to the search system to decide which of the available version (TLI, AVX, AVX2, ...) the system should prefer, when multiple versions with the same VFShape are present. Some of the code in this patch is based on the work done by Sumedh Arani in https://reviews.llvm.org/D66025. [*] Notice that in the proposal the VFDatabase was called SVFS. The name VFDatabase is more in line with LLVM recommendations for naming classes and variables. Differential Revision: https://reviews.llvm.org/D67572
2019-10-07Second attempt to add iterator_range::empty()Jordan Rose1-1/+1
Doing this makes MSVC complain that `empty(someRange)` could refer to either C++17's std::empty or LLVM's llvm::empty, which previously we avoided via SFINAE because std::empty is defined in terms of an empty member rather than begin and end. So, switch callers over to the new method as it is added. https://reviews.llvm.org/D68439 llvm-svn: 373935
2019-09-07Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson1-2/+3
Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
2019-08-16Revert "[CallGraph] Refine call graph for indirect calls with !callees metadata"Benjamin Kramer1-4/+2
This reverts commit r369025. Crashes clang, test case is on the mailing list. llvm-svn: 369096
2019-08-15[CallGraph] Refine call graph for indirect calls with !callees metadataMark Lacey1-2/+4
For indirect call sites having a small set of possible callees, !callees metadata can be used to indicate what those callees are. This patch updates the call graph and lazy call graph analyses so that they consider this metadata when encountering call sites. For the call graph, it adds a new external call graph node to the graph for each unique !callees metadata node. A call graph edge connects an indirect call site with the external node associated with the !callees metadata that is attached to it. And there is an edge from this external node to each of the callees indicated by the metadata. Similarly, for the lazy call graph, the patch adds Ref edges from a caller to the possible callees indicated by the metadata. The primary purpose of the patch is to facilitate iterating over the functions in a module such that all of the callees indicated by a given !callees metadata node will be visited prior to the functions containing call sites annotated by that node. This property is required by optimizations performing a bottom-up traversal of the SCC DAG. For example, the inliner can be made to inline through an indirect call. If the call site is annotated with !callees metadata, this patch ensures that the inliner will have visited all of the callees prior to the caller, allowing it to reliably compute the cost of inlining one or more of the potential callees. Original patch by @mssimpso. I've made some small changes to get it to apply, build, and pass tests on the top of tree, as well as some minor tweaks to formatting and functionality. Subscribers: mehdi_amini, hiraditya, llvm-commits, mssimpso Tags: #llvm Differential Revision: https://reviews.llvm.org/D39339 llvm-svn: 369025
2019-08-06Change two unnecessary uses of llvm::size(C) to C.size()Fangrui Song1-4/+2
llvm-svn: 368011
2019-04-05[LCG] Add aliased functions as LCG rootsGuozhi Wei1-0/+13
Current LCG doesn't check aliased functions. So if an internal function has a public alias it will not be added to CG SCC, but it is still reachable from outside through the alias. So this patch adds aliased functions to SCC. Differential Revision: https://reviews.llvm.org/D59898 llvm-svn: 357795
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
generated by cgit v1.1 at 2025-09-29 02:38:20 +0000