summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Coroutines
Commit message (Collapse)AuthorAgeFilesLines
* [Coroutines] Fix PR45130Jun Ma2020-04-291-1/+4
| | | | | | | | | | For now, when final suspend can be simplified by simplifySuspendPoint, handleFinalSuspend is executed as well to remove last case in switch instruction. This patch fixes it. Differential Revision: https://reviews.llvm.org/D76345 (cherry picked from commit 032251e34d17c1cbf21e7571514bb775ed5cdf30)
* [Coroutines] Remove corresponding phi values when apply ↵Brian Gesiak2020-01-051-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | simplifyTerminatorLeadingToRet Summary: In addMustTailToCoroResumes, we set musttail on those resume instructions that are followed by a ret instruction. This is done by simplifyTerminatorLeadingToRet which replace a sequence of branches leading to a ret with a clone of the ret. However it forgets to remove corresponding PHI values that come from basic block of replaced branch, and may cause jumpthreading pass hangs (https://bugs.llvm.org/show_bug.cgi?id=43720) This patch fix this issue Test Plan: cppcoro library with O3+flto check-llvm Reviewers: modocache, GorNishanov, lewissbaker Reviewed By: modocache Subscribers: mehdi_amini, EricWF, hiraditya, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71826 Patch by junparser (JunMa)!
* [Coroutines] const-ify internal helpers (NFC)Brian Gesiak2020-01-013-11/+13
| | | | | Several helpers internal to llvm/Transforms/Coroutines do not use 'const' for parameters that are not modified. Add const where possible.
* [Coroutines] Rename "legacy" passes (NFC)Brian Gesiak2020-01-016-51/+52
| | | | | | | | | | | | | | | | | | A series of patches beginning with https://reviews.llvm.org/D71898 propose to add an implementation of the coroutine passes to the new pass manager. As part of these changes, the coroutine passes that implement the legacy pass manager interface are renamed, to `<PassName>Legacy`. This mirrors similar changes that have been made to many other passes in LLVM as they've been transitioned to support both old and new pass managers. This commit splits out the renaming portion of that patch and commits it in advance as an NFC (no functional change intended) commit. It renames: * `CoroEarly` => `CoroEarlyLegacy` * `CoroSplit` => `CoroSplitLegacy` * `CoroElide` => `CoroElideLegacy` * `CoroCleanup` => `CoroCleanupLegacy`
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Sink all InitializePasses.h includesReid Kleckner2019-11-133-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)Guillaume Chatelet2019-09-301-1/+1
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, arsenm, jvesely, nhaehnle, eraman, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68141 llvm-svn: 373207
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-153-3/+3
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [coroutine] Fixes "cannot move instruction since its users are not dominated ↵Gor Nishanov2019-08-152-148/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | by CoroBegin" problem. Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=36578 and https://bugs.llvm.org/show_bug.cgi?id=36296. Supersedes: https://reviews.llvm.org/D55966 One of the fundamental transformation that CoroSplit pass performs before splitting the coroutine is to find which values need to survive between suspend and resume and provide a slot for them in the coroutine frame to spill and restore the value as needed. Coroutine frame becomes available once the storage for it was allocated and that point is marked in the pre-split coroutine with a llvm.coro.begin intrinsic. FE normally puts all of the user-authored code that would be accessing those values after llvm.coro.begin, however, sometimes instructions accessing those values would end up prior to coro.begin. For example, writing out a value of the parameter into the alloca done by the FE or instructions that are added by the optimization passes such as SROA when it rewrites allocas. Prior to this change, CoroSplit pass would try to move instructions that may end up accessing the values in the coroutine frame after CoroBegin. However it would run into problems (report_fatal_error) if some of the values would be used both in the allocation function (for example allocator is passed as a parameter to a coroutine) and in the use-authored body of the coroutine. To handle this case and to simplify the instruction moving logic, this change removes all of the instruction moving. Instead, we only change the uses of the spilled values that are dominated by coro.begin and leave other instructions intact. Before: ``` %var = alloca i32 %1 = getelementptr .. %var; ; will move this one after coro.begin %f = call i8* @llvm.coro.begin( ``` After: ``` %var = alloca i32 %1 = getelementptr .. %var; stays put %f = call i8* @llvm.coro.begin( ``` If we discover that there is a potential write into an alloca, prior to coro.begin we would copy its value from the alloca into the spill slot in the coroutine frame. Before: ``` %var = alloca i32 store .. %var ; will move this one after coro.begin %f = call i8* @llvm.coro.begin( ``` After: ``` %var = alloca i32 store .. %var ;stays put %f = call i8* @llvm.coro.begin( %tmp = load %var store %tmp, %spill.slot.for.var ``` Note: This change does not handle array allocas as that is something that C++ FE does not produce, but, it can be added in the future if need arises Reviewers: llvm-commits, modocache, ben-clayton, tks2103, rjmccall Reviewed By: modocache Subscribers: bartdesmet Differential Revision: https://reviews.llvm.org/D66230 llvm-svn: 368949
* Fix "not all control paths return a value" MSVC warnings. NFCI.Simon Pilgrim2019-08-141-1/+4
| | | | llvm-svn: 368831
* Fix "not all control paths return a value" MSVC warning. NFCI.Simon Pilgrim2019-08-141-0/+1
| | | | llvm-svn: 368830
* Fix "not all control paths return a value" MSVC warnings. NFCI.Simon Pilgrim2019-08-141-0/+2
| | | | llvm-svn: 368829
* Coroutines: adjust for SVN r358739John McCall2019-08-141-4/+6
| | | | | | | CallSite has been removed in favour of CallBase. Adjust the coroutine split to account for that. llvm-svn: 368798
* Don't run a full verifier pass in coro-splitting's private pipeline.John McCall2019-08-141-1/+6
| | | | | | Potentially addresses rdar://49022293. llvm-svn: 368797
* Remove unreachable blocks before splitting a coroutine.John McCall2019-08-141-1/+19
| | | | | | | The suspend-crossing algorithm is not correct in the presence of uses that cannot be reached on some successor path from their defs. llvm-svn: 368796
* Support swifterror in coroutine lowering.John McCall2019-08-143-0/+238
| | | | | | | | | | The support for swifterror allocas should work in all lowerings. The support for swifterror arguments only really works in a lowering with prototypes where you can ensure that the prototype also has a swifterror argument; I'm not really sure how it could possibly be made to work in the switch lowering. llvm-svn: 368795
* In coro.retcon lowering, don't explode if the optimizer messes around with ↵John McCall2019-08-142-1/+28
| | | | | | the linkage of the prototype or the exact types of the yielded values. llvm-svn: 368793
* Fix a use-after-free in the coro.alloca treatment.John McCall2019-08-141-4/+10
| | | | llvm-svn: 368792
* Add intrinsics for doing frame-bound dynamic allocations within a coroutine.John McCall2019-08-143-4/+241
| | | | | | | These rely on having an allocator provided to the coroutine and thus, for now, only work in retcon lowerings. llvm-svn: 368791
* Guard dumps in the coro intrinsic validation logic behind NDEBUG checks. ↵John McCall2019-08-141-0/+14
| | | | | | dump() is not guaranteed to be defined in all builds. llvm-svn: 368790
* Generalize llvm.coro.suspend.retcon to allow an arbitrary number of ↵John McCall2019-08-143-24/+93
| | | | | | arguments to be passed back to the continuation function. llvm-svn: 368789
* Extend coroutines to support a "returned continuation" lowering.John McCall2019-08-147-271/+1432
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A quick contrast of this ABI with the currently-implemented ABI: - Allocation is implicitly managed by the lowering passes, which is fine for frontends that are fine with assuming that allocation cannot fail. This assumption is necessary to implement dynamic allocas anyway. - The lowering attempts to fit the coroutine frame into an opaque, statically-sized buffer before falling back on allocation; the same buffer must be provided to every resume point. A buffer must be at least pointer-sized. - The resume and destroy functions have been combined; the continuation function takes a parameter indicating whether it has succeeded. - Conversely, every suspend point begins its own continuation function. - The continuation function pointer is directly returned to the caller instead of being stored in the frame. The continuation can therefore directly destroy the frame when exiting the coroutine instead of having to leave it in a defunct state. - Other values can be returned directly to the caller instead of going through a promise allocation. The frontend provides a "prototype" function declaration from which the type, calling convention, and attributes of the continuation functions are taken. - On the caller side, the frontend can generate natural IR that directly uses the continuation functions as long as it prevents IPO with the coroutine until lowering has happened. In combination with the point above, the frontend is almost totally in charge of the ABI of the coroutine. - Unique-yield coroutines are given some special treatment. llvm-svn: 368788
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-163-3/+3
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song2019-06-211-1/+1
| | | | llvm-svn: 364006
* [coroutines] Add missing pass dependency.Gor Nishanov2019-06-181-1/+6
| | | | | | | | | | | | | | | | | | | | | Summary: CoroSplit depends on CallGraphWrapperPass, but it was not explicitly adding it as a pass dependency. This missing dependency can trigger errors / assertions / crashes in PMTopLevelManager::schedulePass() under certain configurations. Author: ben-clayton Reviewers: GorNishanov Reviewed By: GorNishanov Subscribers: capn, EricWF, modocache, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63144 llvm-svn: 363727
* [coroutines] Fix spills of static array allocasGor Nishanov2019-05-131-6/+39
| | | | | | | | | | | | | | | | | | | | | | | Summary: CoroFrame was not considering static array allocas, and was only ever reserving a single element in the coroutine frame. This meant that stores to the non-zero'th element would corrupt later frame data. Store static array allocas as field arrays in the coroutine frame. Added test. Committed by Gor Nishanov on behalf of ben-clayton Reviewers: GorNishanov, modocache Reviewed By: GorNishanov Subscribers: Orlando, capn, EricWF, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61372 llvm-svn: 360636
* [CallSite removal] Move the legacy PM, call graph, and some inlinerChandler Carruth2019-04-191-4/+4
| | | | | | | | | | | | code to `CallBase`. This patch focuses on the legacy PM, call graph, and some of inliner and legacy passes interacting with those APIs from `CallSite` to the new `CallBase` class. No interesting changes. Differential Revision: https://reviews.llvm.org/D60412 llvm-svn: 358739
* [coroutines][PR40979] Ignore unreachable uses across suspend pointsBrian Gesiak2019-03-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Depends on https://reviews.llvm.org/D59069. https://bugs.llvm.org/show_bug.cgi?id=40979 describes a bug in which the -coro-split pass would assert that a use was across a suspend point from a definition. Normally this would mean that a value would "spill" across a suspend point and thus need to be stored in the coroutine frame. However, in this case the use was unreachable, and so it would not be necessary to store the definition on the frame. To prevent the assert, simply remove unreachable basic blocks from a coroutine function before computing spills. This avoids the assert reported in PR40979. Reviewers: GorNishanov, tks2103 Reviewed By: GorNishanov Subscribers: EricWF, jdoerfert, llvm-commits, lewissbaker Tags: #llvm Differential Revision: https://reviews.llvm.org/D59068 llvm-svn: 355852
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-014-7/+8
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-2/+5
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-199-36/+27
| | | | | | | | | | | | | | | | | 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
* Fix compiler warning about unused variable [NFC]Mikael Holmen2018-12-121-1/+1
| | | | llvm-svn: 348913
* [coroutines] Improve suspend point simplificationGor Nishanov2018-12-111-32/+100
| | | | | | | | | | | | | | | | | Summary: Enable suspend point simplification for cases where: * coro.save and coro.suspend are in different basic blocks * where there are intervening intrinsics Reviewers: modocache, tks2103, lewissbaker Reviewed By: modocache Subscribers: EricWF, llvm-commits Differential Revision: https://reviews.llvm.org/D55160 llvm-svn: 348897
* [TI removal] Make `getTerminator()` return a generic `Instruction`.Chandler Carruth2018-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This removes the primary remaining API producing `TerminatorInst` which will reduce the rate at which code is introduced trying to use it and generally make it much easier to remove the remaining APIs across the codebase. Also clean up some of the stragglers that the previous mechanical update of variables missed. Users of LLVM and out-of-tree code generally will need to update any explicit variable types to handle this. Replacing `TerminatorInst` with `Instruction` (or `auto`) almost always works. Most of these edits were made in prior commits using the perl one-liner: ``` perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g' ``` This also my break some rare use cases where people overload for both `Instruction` and `TerminatorInst`, but these should be easily fixed by removing the `TerminatorInst` overload. llvm-svn: 344504
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-1/+1
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-262-2/+3
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Sink `isExceptional` predicate to `Instruction`, rename it toChandler Carruth2018-08-261-1/+1
| | | | | | | | | | | `isExceptionalTermiantor` and implement it for opcodes as well following the common pattern in `Instruction`. Part of removing `TerminatorInst` from the `Instruction` type hierarchy to make it easier to share logic and interfaces between instructions that are both terminators and not terminators. llvm-svn: 340699
* [LLVM-C] Add coroutine passeswhitequark2018-08-191-0/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D50950 llvm-svn: 340147
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-043-3/+3
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-142-18/+18
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [Coroutines] PR34897: Fix incorrect elisionsBrian Gesiak2018-05-111-13/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://bugs.llvm.org/show_bug.cgi?id=34897 demonstrates an incorrect coroutine frame allocation elision in the coro-elide pass. The elision is performed on the basis that the SSA variables from all llvm.coro.begin are directly referenced in subsequent llvm.coro.destroy instructions. However, this ignores the fact that the function may exit through paths that do not run these destroy instructions. In the sample program from PR34897, for example, the llvm.coro.destroy instruction is only executed in exception handling code. When the coroutine function exits normally, llvm.coro.destroy is not called. Eliding the allocation in this case causes a subsequent reference to the coroutine handle from outside of the function to access freed memory. To fix the issue, when finding an llvm.coro.destroy for each llvm.coro.begin, only consider llvm.coro.destroy that are executed along non-exceptional paths. Test Plan: 1. Download the sample program from https://bugs.llvm.org/show_bug.cgi?id=34897, compile it with `clang++ -fcoroutines-ts -stdlib=libc++ -std=c++1z -O2`, and run it. It should print `"run1\ncheck1\nrun2\ncheck2"` and then exit successfully. 2. Compile https://godbolt.org/g/mCKfnr and confirm it is still optimized to a single instruction, 'return 1190'. 3. `check-llvm` Reviewers: rsmith, GorNishanov, eric_niebler Reviewed By: GorNishanov Subscribers: andrewrk, lewissbaker, EricWF, llvm-commits Differential Revision: https://reviews.llvm.org/D43242 llvm-svn: 332077
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [Transforms] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: kcc, pcc, danielcdh, jmolloy, sanjoy, dberlin, ruiu Reviewed By: ruiu Subscribers: ruiu, llvm-commits Differential Revision: https://reviews.llvm.org/D45142 llvm-svn: 330059
* Remove trailing space in build file.Nico Weber2018-04-071-1/+1
| | | | llvm-svn: 329479
* Make helpers static. NFC.Benjamin Kramer2018-04-041-0/+2
| | | | llvm-svn: 329170
* [coroutines] Respect alloca alignment requirements when building coroutine frameGor Nishanov2018-04-032-9/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If an alloca need to be stored in the coroutine frame and it has an alignment specified and the alignment does not match the natural alignment of the alloca type. Insert appropriate padding into the coroutine frame to make sure that it gets requested alignment. For example for a packet type (which natural alignment is 1), but alloca alignment is 8, we may need to insert a padding field with required number of bytes to make sure it is properly aligned. ``` %PackedStruct = type <{ i64 }> ... %data = alloca %PackedStruct, align 8 ``` If the previous field in the coroutine frame had alignment 2, we would have [6 x i8] inserted before %PackedStruct in the coroutine frame: ``` %f.Frame = type { ..., i16, [6 x i8], %PackedStruct } ``` Reviewers: rnk, lewissbaker, modocache Reviewed By: modocache Subscribers: EricWF, llvm-commits Differential Revision: https://reviews.llvm.org/D45221 llvm-svn: 329112
* [Coroutines] Avoid assert splitting hidden corosBrian Gesiak2018-04-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When attempting to split a coroutine with 'hidden' visibility (for example, a C++ coroutine that is inlined when compiled with the option '-fvisibility-inlines-hidden'), LLVM would hit an assertion in include/llvm/IR/GlobalValue.h:240: "local linkage requires default visibility". The issue is that the visibility is copied from the source of the function split in the `CloneFunctionInto` function, but the linkage is not. To fix, create the new function first with external linkage, then copy the linkage from the original function *after* `CloneFunctionInto` is called. Since `GlobalValue::setLinkage` in turn calls `maybeSetDsoLocal`, the explicit call to `setDSOLocal` can be removed in CoroSplit.cpp. Test Plan: check-llvm Reviewers: GorNishanov, lewissbaker, EricWF, majnemer, rnk Reviewed By: rnk Subscribers: llvm-commits, eric_niebler Differential Revision: https://reviews.llvm.org/D44185 llvm-svn: 329033
* [coroutines] Add support for llvm.coro.noop intrinsicsGor Nishanov2018-04-022-7/+48
| | | | | | | | | | | | | | | | Summary: A recent addition to Coroutines TS (https://wg21.link/p0913) adds a pre-defined coroutine noop_coroutine that does nothing. To implement this feature, we implemented an llvm.coro.noop intrinsic that returns a coroutine handle to a coroutine that does nothing when resumed or destroyed. Reviewers: EricWF, modocache, rnk, lewissbaker Reviewed By: modocache Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45114 llvm-svn: 328986
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-213-4/+4
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* Remove unused variable; NFCGeorge Burgess IV2018-03-151-1/+0
| | | | llvm-svn: 327597
OpenPOWER on IntegriCloud