summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Recommit "[ThinLTO] Add correctness check for RO/WO variable import"evgeny2019-11-151-4/+3
| | | | | | ValueInfo has user-defined 'operator bool' which allows incorrect implicit conversion to GlobalValue::GUID (which is unsigned long). This causes bugs which are hard to track and should be removed in future.
* Add missing includes needed to prune LLVMContext.h include, NFCReid Kleckner2019-11-141-0/+1
| | | | | These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280
* Revert "[ThinLTO] Add correctness check for RO/WO variable import"Benjamin Kramer2019-11-141-3/+4
| | | | | This reverts commit a2292cc537b561416c21e8d4017715d652c144cc. Breaks clang selfhost w/ThinLTO.
* [ThinLTO] Add correctness check for RO/WO variable importevgeny2019-11-141-4/+3
| | | | | | | | | | | This patch adds an assertion check for exported read/write-only variables to be also in import list for module. If they aren't we may face linker errors, because read/write-only variables are internalized in their source modules. The patch also changes export lists to store ValueInfo instead of GUID for performance considerations. Differential revision: https://reviews.llvm.org/D70128
* Move CodeGenFileType enum to Support/CodeGen.hReid Kleckner2019-11-131-1/+1
| | | | | | | Avoids the need to include TargetMachine.h from various places just for an enum. Various other enums live here, such as the optimization level, TLS model, etc. Data suggests that this change probably doesn't matter, but it seems nice to have anyway.
* Fix compilation warning on the trailing whitespace. NFC.Michael Liao2019-10-241-1/+1
|
* Hide implementation details in anonymous namespaces. NFC.Benjamin Kramer2019-10-241-0/+2
|
* [ThinLTOCodeGenerator] Add support for index-based WPDEugene Leviant2019-10-181-21/+47
| | | | | | Differential revision: https://reviews.llvm.org/D68950 llvm-svn: 375219
* [Support] Add overload writeFileAtomically(std::function Writer)Jan Korous2019-09-131-14/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D67424 llvm-svn: 371890
* AArch64: support arm64_32, an ILP32 slice for watchOS.Tim Northover2019-09-121-1/+2
| | | | | | | | This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM. FastISel is mostly disabled for now since it would generate incorrect code for ILP32. llvm-svn: 371722
* [ThinLTO] Fix handling of weak interposable symbolsTeresa Johnson2019-08-231-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Keep aliasees alive if their alias is live, otherwise we end up with an alias to a declaration, which is invalid. This can happen when the aliasee is weak and non-prevailing. This fix exposed the fact that we were then attempting to internalize the weak symbol, which was not exported as it was not prevailing. We should not internalize interposable symbols in general, unless this is the prevailing copy, since it can lead to incorrect inlining and other optimizations. Most of the changes in this patch are due to the restructuring required to pass down the prevailing callback. Finally, while implementing the test cases, I found that in the case of a weak aliasee that is still marked not live because its alias isn't live, after dropping the definition we incorrectly marked the declaration with weak linkage when resolving prevailing symbols in the module. This was due to some special case handling for symbols marked WeakLinkage in the summary located before instead of after a subsequent check for the symbol being a declaration. It turns out that we don't actually need this special case handling any more (looking back at the history, when that was added the code was structured quite differently) - we will correctly mark with weak linkage further below when the definition hasn't been dropped. Fixes PR42542. Reviewers: pcc Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66264 llvm-svn: 369766
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-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
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-3/+3
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Open native file handles to avoid converting from FDs, NFCReid Kleckner2019-07-111-8/+6
| | | | | | Follow up to r365588. llvm-svn: 365820
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-171-1/+2
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* Reland: [Remarks] Refactor optimization remarks setupFrancis Visoiu Mistrih2019-06-141-5/+6
| | | | | | | | * Add a common function to setup opt-remarks * Rename common options to the same names * Add error types to distinguish between file errors and regex errors llvm-svn: 363415
* Revert "[Remarks] Refactor optimization remarks setup"Francis Visoiu Mistrih2019-06-141-6/+5
| | | | | | | | This reverts commit 6e6e3af55bb97e1a4c97375c15a2b0099120c5a7. This breaks greendragon. llvm-svn: 363343
* [Remarks] Refactor optimization remarks setupFrancis Visoiu Mistrih2019-06-131-5/+6
| | | | | | | | * Add a common function to setup opt-remarks * Rename common options to the same names * Add error types to distinguish between file errors and regex errors llvm-svn: 363328
* [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligibleTeresa Johnson2019-05-101-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We hit undefined references building with ThinLTO when one source file contained explicit instantiations of a template method (weak_odr) but there were also implicit instantiations in another file (linkonce_odr), and the latter was the prevailing copy. In this case the symbol was marked hidden when the prevailing linkonce_odr copy was promoted to weak_odr. It led to unsats when the resulting shared library was linked with other code that contained a reference (expecting to be resolved due to the explicit instantiation). Add a CanAutoHide flag to the GV summary to allow the thin link to identify when all copies are eligible for auto-hiding (because they were all originally linkonce_odr global unnamed addr), and only do the auto-hide in that case. Most of the changes here are due to plumbing the new flag through the bitcode and llvm assembly, and resulting test changes. I augmented the existing auto-hide test to check for this situation. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, arphaman, dang, llvm-commits, steven_wu, wmi Tags: #llvm Differential Revision: https://reviews.llvm.org/D59709 llvm-svn: 360466
* [ThinLTO] Adding architecture name into saved object filenameSteven Wu2019-04-291-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For ThinLTOCodegenerator, it has an option to save the object file outputs into a directory which is essential for debug info. Tools like lldb and dsymutil will look for these object files for debug info. On Darwin platform, you can link fat binaries with one single clang driver invocation like: $ clang -arch x86_64 -arch i386 -Wl,-object_path_lto,$TMPDIR ... Unfornately, the output object files for one architecture is going to overwrite the previous ones and one architecture slice will end up with no debug info. One example for this is to turn on ThinLTO for sanitizer dylibs in compiler-rt project. To fix the issue, add the name for the architecture into the name of the output object file. rdar://problem/35482935 Reviewers: tejohnson, bd1976llvm, dexonsmith, JDevlieghere Reviewed By: dexonsmith Subscribers: mehdi_amini, aprantl, inglorion, eraman, hiraditya, jkorous, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60924 llvm-svn: 359508
* [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbolsSteven Wu2019-04-171-51/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reapply r357931 with fixes to ThinLTO testcases and llvm-lto tool. ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. Now ThinLTO using the legacy LTO API will requires data layout in Module. "internalize" thinlto action in llvm-lto is updated to run both "promote" and "internalize" with the same configuration as ThinLTOCodeGenerator. The old "promote" + "internalize" option does not produce the same output as ThinLTOCodeGenerator. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, kromanova, dexonsmith Reviewed By: tejohnson Subscribers: ormris, bd1976llvm, mehdi_amini, inglorion, eraman, hiraditya, jkorous, dexonsmith, arphaman, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60421 llvm-svn: 358601
* Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbolsSteven Wu2019-04-081-80/+52
| | | | | | This reverts r357931 (git commit 8b70a5c11e08116955a875b9085433f14737bcaf) llvm-svn: 357932
* [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbolsSteven Wu2019-04-081-52/+80
| | | | | | | | | | | | | | | | | | | | | | | Summary: ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, dexonsmith Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, eraman, hiraditya, jkorous, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60226 llvm-svn: 357931
* Reland "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 llvm-svn: 355984
* Revert "[Remarks] Add -foptimization-record-passes to filter remark emission"Francis Visoiu Mistrih2019-03-121-3/+1
| | | | | | This reverts commit 20fff32b7d1f1a1bd417b22aa9f26ededd97a3e5. llvm-svn: 355976
* [Remarks] Add -foptimization-record-passes to filter remark emissionFrancis Visoiu Mistrih2019-03-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 llvm-svn: 355964
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* [ThinLTO] Compute synthetic function entry countEaswaran Raman2018-12-131-0/+4
| | | | | | | | | | | | | | | | | Summary: This patch computes the synthetic function entry count on the whole program callgraph (based on module summary) and writes the entry counts to the summary. After function importing, this count gets attached to the IR as metadata. Since it adds a new field to the summary, this bumps up the version. Reviewers: tejohnson Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D43521 llvm-svn: 349076
* [ThinLTO] Import local variables from the same module as callerTeresa Johnson2018-11-291-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We can sometimes end up with multiple copies of a local variable that have the same GUID in the index. This happens when there are local variables with the same name that are in different source files having the same name/path at compile time (but compiled into different bitcode objects). In this case make sure we import the copy in the caller's module. This enables importing both of the variables having the same GUID (but which will have different promoted names since the module paths, and therefore the module hashes, will be distinct). Importing the wrong copy is particularly problematic for read only variables, since we must import them as a local copy whenever referenced. Otherwise we get undefs at link time. Note that the llvm-lto.cpp and ThinLTOCodeGenerator changes are needed for testing the distributed index case via clang, which will be sent as a separate clang-side patch shortly. We were previously not doing the dead code/read only computation before computing imports when testing distributed index generation (like it was for testing importing and other ThinLTO mechanisms alone). Reviewers: evgeny777 Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D55047 llvm-svn: 347886
* [ThinLTO] Consolidate cache key computation between new/old LTO APIsTeresa Johnson2018-11-261-87/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The old legacy LTO API had a separate cache key computation, which was a subset of the cache key computation in the new LTO API (from what I can tell this is largely just because certain features such as CFI, dsoLocal, etc are only utilized via the new LTO API). However, having separate computations is unnecessary (much of the code is duplicated), and can lead to bugs when adding new optimizations if both cache computation algorithms aren't updated properly - it's much easier to maintain if we have a single facility. This patch refactors the old LTO API code to use the cache key computation from the new LTO API. To do this, we set up an lto::Config object and fill in the fields that the old LTO was hashing (the others will just use the defaults). There are two notable changes: - I added a Freestanding flag to the LTO Config. Currently this is only used by the legacy LTO API. In the patch that added it (D30791) I had asked about adding it to the new LTO API, but it looks like that was not addressed. This should probably be discussed as a follow up to this change, as it is orthogonal. - The legacy LTO API had some code that was hashing the GUID of all preserved symbols defined in the module. I looked back at the history of this (which was added with the original hashing in the legacy LTO API in D18494), and there is a comment in the review thread that it was added in preparation for future internalization. We now do the internalization of course, and that is handled in the new LTO API cache key computation by hashing the recorded linkage type of all defined globals. Therefore I didn't try to move over and keep the preserved symbols handling. Reviewers: steven_wu, pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D54635 llvm-svn: 347592
* [ThinLTO] Internalize readonly globalsEugene Leviant2018-11-161-5/+14
| | | | | | | | An attempt to recommit r346584 after failure on OSX build bot. Fixed cache key computation in ThinLTOCodeGenerator and added test case llvm-svn: 347033
* Revert "[ThinLTO] Internalize readonly globals"Steven Wu2018-11-131-2/+1
| | | | | | This reverts commit 10c84a8f35cae4a9fc421648d9608fccda3925f2. llvm-svn: 346768
* [ThinLTO] Internalize readonly globalsEugene Leviant2018-11-101-1/+2
| | | | | | | | | This patch allows internalising globals if all accesses to them (from live functions) are from non-volatile load instructions Differential revision: https://reviews.llvm.org/D49362 llvm-svn: 346584
* [LTO] Drop non-prevailing definitions only if linkage is not local or appendingPirama Arumuga Nainar2018-11-081-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR 37422 In ELF, non-weak symbols can also be non-prevailing. In this particular PR, the __llvm_profile_* symbols are non-prevailing but weren't getting dropped - causing multiply-defined errors with lld. Also add a test, strong_non_prevailing.ll, to ensure that multiple copies of a strong symbol are dropped. To fix the test regressions exposed by this fix, - do not mark prevailing copies for symbols with 'appending' linkage. There's no one prevailing copy for such symbols. - fix the prevailing version in dead-strip-fulllto.ll - explicitly pass exported symbols to llvm-lto in fumcimport.ll and funcimport_var.ll Reviewers: tejohnson, pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, dang, srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D54125 llvm-svn: 346436
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-6/+5
| | | | | | | | | | | | 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
* [PassTiming] cleaning up legacy PassTimingInfo interface. NFCI.Fedor Sergeev2018-09-261-0/+1
| | | | | | | | | | | | | | | | | | | | During D51276 discussion it was decided that legacy PassTimingInfo interface can not be reused for new pass manager's implementation of -time-passes. This is a cleanup in preparation for D51276 to make legacy interface as concise as possible, moving the PassTimingInfo from the header into the anonymous legacy namespace in .cpp. It is rather close to a revert of rL340872 in a sense that it hides the interface and gets rid of templates. However as compared to a complete revert it resides in a different translation unit and has an additional pass-instance counting funcitonality (PassIDCountMap). Reviewers: philip.pfaffe Differential Revision: https://reviews.llvm.org/D52356 llvm-svn: 343104
* [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPoolSteven Wu2018-09-141-5/+9
| | | | | | | | | | | | | | | | | | | | Summary: During threaded thinLTO, it is possible that the entry for current module doesn't exist in StringMaps (like ExportLists, ResolvedODR, etc.). Using operator[] might trigger a rehash for the StringMap, which might happen on multiple threads at the same time. rdar://problem/43846199 Reviewers: tejohnson, mehdi_amini, kromanova, pcc Reviewed By: tejohnson Subscribers: dang, inglorion, eraman, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D52049 llvm-svn: 342263
* [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was ↵Steven Wu2018-09-041-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified Summary: Issue occurs when doing ThinLTO with CodeGenOnly flag. TMBuilder.TheTriple is assigned to by multiple threads in an unsafe way resulting in double-free of std::string memory. Pseudocode: if (CodeGenOnly) { // Perform only parallel codegen and return. ThreadPool Pool; int count = 0; for (auto &ModuleBuffer : Modules) { Pool.async([&](int count) { ... /// Now call OutputBuffer = codegen(*TheModule); /// Which turns into initTMBuilder(moduleTMBuilder, Triple(TheModule.getTargetTriple())); /// Which turns into TMBuilder.TheTriple = std::move(TheTriple); // std::string = "....." /// So, basically std::string assignment to same string on multiple threads = memory corruption } return; } Patch by Alex Borcan Reviewers: llvm-commits, steven_wu Reviewed By: steven_wu Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51651 llvm-svn: 341422
* Remove trailing spaceFangrui Song2018-07-301-5/+5
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [ThinLTO] Use std::map to get determistic imports filesTeresa Johnson2018-07-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: I noticed that the .imports files emitted for distributed ThinLTO backends do not have consistent ordering. This is because StringMap iteration order is not guaranteed to be deterministic. Since we already have a std::map with this information, used when emitting the individual index files (ModuleToSummariesForIndex), use it for the imports files as well. This issue is likely causing some unnecessary rebuilds of the ThinLTO backends in our distributed build system as the imports files are inputs to those backends. Reviewers: pcc, steven_wu, mehdi_amini Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48783 llvm-svn: 336721
* [ThinLTO] Update ThinLTO cache file atimes when on WindowsAndrew Ng2018-07-041-1/+18
| | | | | | | | | | | | | | | | | | ThinLTO cache file access times are used for expiration based pruning and since Vista, file access times are not updated by Windows by default: https://blogs.technet.microsoft.com/filecab/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance This means on Windows, cache files are currently being pruned from creation time. This change manually updates cache files that are accessed by ThinLTO, when on Windows. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D47266 llvm-svn: 336276
* [ThinLTO] Rename index IsAnalysis flag to HaveGVs (NFC)Teresa Johnson2018-06-061-1/+1
| | | | | | | | | With the upcoming patch to add summary parsing support, IsAnalysis would be true in contexts where we are not performing module summary analysis. Rename to the more specific and approprate HaveGVs, which is essentially what this flag is indicating. llvm-svn: 334140
* CodeGen: Add a dwo output file argument to addPassesToEmitFile and hook it ↵Peter Collingbourne2018-05-211-1/+1
| | | | | | | | | | up to dwo output. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47089 llvm-svn: 332881
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-3/+3
| | | | | | | | | | | | | | | | 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
* 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
* Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCIWeiming Zhao2018-04-161-3/+3
| | | | | | | | | | | | | | Summary: As discussed in https://reviews.llvm.org/D45606, it makes more sense to name the class as SmallVectorMemoryBuffer Reviewers: bkramer, dblaikie Reviewed By: dblaikie Subscribers: mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D45661 llvm-svn: 330107
* NFC: Move ObjectMemoryBuffer to supportWeiming Zhao2018-04-151-1/+1
| | | | | | | | | | | | | | | | Summary: Since the class is used by both MCJIT and LTO, it makes more sense to move it to Support lib. This is a follow up patch to r329929 and https://reviews.llvm.org/D45244 Reviewers: bkramer, dblaikie Reviewed By: bkramer Subscribers: mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D45606 llvm-svn: 330093
* [LTO] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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 D44363 for a list of all the required patches. Reviewers: pcc, mehdi_amini, ruiu Reviewed By: ruiu Subscribers: ruiu, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D45137 llvm-svn: 330053
* Prevent data races in concurrent ThinLTO processes.Ekaterina Romanova2018-03-301-17/+14
| | | | | | | | | | | | Make sure ThinLTO with caching doesn't use non-atomic writes to the cache file (to prevent data races and cache files corruption). 1. Place temp file to the same place where the caching directory is (instead of creating it the directory pointed to by TMP/TEMP variable). This will help to prevent using non-atomic rename and falling back to non-atomic "direct" write to the cache file. 2. if rename failed do not write to the cache file directly (direct write to the file is non-atomic and could cause data race conditions). 3. if cache file doesn't exist (e.g., because 'rename' failed or because some other reasons), bypass using the cache altogether. Differential Revision: https://reviews.llvm.org/D45076 llvm-svn: 328904
OpenPOWER on IntegriCloud