summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Fix clang-interpreter example code broken by r368707.Douglas Yung2019-08-141-3/+4
| | | | llvm-svn: 368778
* [analyzer][NFC] Prepare visitors for different tracking kindsKristof Umann2019-08-145-88/+121
| | | | | | | | | | | | | | | | | | | | | | | When we're tracking a variable that is responsible for a null pointer dereference or some other sinister programming error, we of course would like to gather as much information why we think that the variable has that specific value as possible. However, the newly introduced condition tracking shows that tracking all values this thoroughly could easily cause an intolerable growth in the bug report's length. There are a variety of heuristics we discussed on the mailing list[1] to combat this, all of them requiring to differentiate in between tracking a "regular value" and a "condition". This patch introduces the new `bugreporter::TrackingKind` enum, adds it to several visitors as a non-optional argument, and moves some functions around to make the code a little more coherent. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-June/062613.html Differential Revision: https://reviews.llvm.org/D64270 llvm-svn: 368777
* Update Python tests for lldb-server on WindowsAaron Smith2019-08-1417-17/+87
| | | | | | | | | | | | | | | | Summary: Thanks to Hui Huang and reviewers for all the help with this patch! Reviewers: labath, jfb, clayborg Reviewed By: labath Subscribers: Hui, clayborg, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61687 llvm-svn: 368776
* [AArch64][GlobalISel] RBS: Treat s128s like vectors when unmerging.Amara Emerson2019-08-132-1/+25
| | | | | | | | The destinations should be FPRs (for now). Differential Revision: https://reviews.llvm.org/D66184 llvm-svn: 368775
* Enable lldb-server on WindowsAaron Smith2019-08-136-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit contains three small changes to enable lldb-server on Windows. - Add lldb-server for Windows to the build - Disable pty redirection on Windows for the initial lldb-server bring up - Add a support to get the parent pid for a process on Windows - Ifdef some signals which aren't supported on Windows Thanks to Hui Huang for the help with this patch! Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61686 llvm-svn: 368774
* [analyzer] Track the right hand side of the last store regardless of its valueKristof Umann2019-08-134-28/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following code snippet taken from D64271#1572188 has an issue: namely, because `flag`'s value isn't undef or a concrete int, it isn't being tracked. int flag; bool coin(); void foo() { flag = coin(); } void test() { int *x = 0; int local_flag; flag = 1; foo(); local_flag = flag; if (local_flag) x = new int; foo(); local_flag = flag; if (local_flag) *x = 5; } This, in my opinion, makes no sense, other values may be interesting too. Originally added by rC185608. Differential Revision: https://reviews.llvm.org/D64287 llvm-svn: 368773
* [DebugLine] Be more robust in geussing the path styleJonas Devlieghere2019-08-131-3/+9
| | | | | | | | My previous change didn't fix the Windows bot. This patch is an attempt to make guessing the path style more robust by first looking at the compile dir and falling back to the actual file if that's unsuccessful. llvm-svn: 368772
* [analyzer] Prune calls to functions with linear CFGs that return a non-zero ↵Kristof Umann2019-08-134-49/+160
| | | | | | | | | | | | | | | | constrained value During the evaluation of D62883, I noticed a bunch of totally meaningless notes with the pattern of "Calling 'A'" -> "Returning value" -> "Returning from 'A'", which added no value to the report at all. This patch (not only affecting tracked conditions mind you) prunes diagnostic messages to functions that return a value not constrained to be 0, and are also linear. Differential Revision: https://reviews.llvm.org/D64232 llvm-svn: 368771
* [AArch64] Remove incorrect usage of MONonTemporal.Eli Friedman2019-08-131-2/+1
| | | | | | | This has no effect at the moment, but might matter if we try to implement non-temporal loads in the future. llvm-svn: 368770
* [analyzer] exploded-graph-rewriter: Implement displaying Store pointers.Artem Dergachev2019-08-133-1/+6
| | | | | | | | | They're useful when trying to understand what's going on inside your LazyCompoundValues. Differential Revision: https://reviews.llvm.org/D65427 llvm-svn: 368769
* [analyzer] exploded-graph-rewriter: Implement manual graph trimming.Artem Dergachev2019-08-132-11/+75
| | | | | | | | | | | | | | | | | | | When -trim-egraph is unavailable (say, when you're debugging a crash on a real-world code that takes too long to reduce), it makes sense to view the untrimmed graph up to the crashing node's predecessor, then dump the ID (or a pointer) of the node in the attached debugger, and then trim the dumped graph in order to keep only paths from the root to the node. The newly added --to flag does exactly that: $ exploded-graph-rewriter.py ExprEngine.dot --to 0x12229acd0 Multiple nodes can be specified. Stable IDs of nodes can be used instead of pointers. Differential Revision: https://reviews.llvm.org/D65345 llvm-svn: 368768
* [analyzer] exploded-graph-rewriter: NFC: Refactor explorers into trimmers.Artem Dergachev2019-08-132-26/+33
| | | | | | | | | | | | | | | | | | | | | | | Explorers aren't the right abstraction. For the purposes of displaying svg files we don't care in which order do we explore the nodes. We may care about this for other analyses, but we're not there yet. The function of cutting out chunks of the graph is performed poorly by the explorers, because querying predecessors/successors on the explored nodes yields original successors/predecessors even if they aren't being explored. Introduce a new entity, "trimmers", that do one thing but to it right: cut out chunks of the graph. Trimmers mutate the graph, so stale edges aren't even visible to their consumers in the pipeline. Additionally, trimmers are intrinsically composable: multiple trimmers can be applied to the graph sequentially. Refactor the single-path explorer into the single-path trimmer. Rename the test file for consistency. Differential Revision: https://reviews.llvm.org/D65344 llvm-svn: 368767
* [analyzer] exploded-graph-rewriter: Open the converted graph immediately.Artem Dergachev2019-08-132-8/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | Change the default behavior: the tool no longer dumps the rewritten .dot file to stdout, but instead it automatically converts it into an .html file (which essentially wraps an .svg file) and immediately opens it with the default web browser. This means that the tool should now be fairly easy to use: $ exploded-graph-rewriter.py /tmp/ExprEngine.dot The benefits of wrapping the .svg file into an .html file are: - It'll open in a web browser, which is the intended behavior. An .svg file would be open with an image viewer/editor instead. - It avoids the white background around the otherwise dark svg area in dark mode. The feature can be turned off by passing a flag '--rewrite-only'. The LIT substitution is updated to enforce the old mode because we don't want web browsers opening on our buildbots. Differential Revision: https://reviews.llvm.org/D65250 llvm-svn: 368766
* [analyzer] Disable the checker-plugins test on Darwin.Artem Dergachev2019-08-131-0/+4
| | | | | | Fixes a buildbot. llvm-svn: 368765
* [ORC] Fix SpeculativeJIT example code broken by r368707.Lang Hames2019-08-131-6/+7
| | | | llvm-svn: 368764
* [Polly-ACC] Fix test after IR-printer change.Michael Kruse2019-08-131-1/+1
| | | | | | | After r367755, even unnamed parameters are printed in IR dumps. Change the test to expect te additional %0 in the line. llvm-svn: 368763
* [clang][DirectoryWatcher] Fix Windows stub after LLVM changeJan Korous2019-08-131-2/+4
| | | | | | | | | r367979 changed DirectoryWatcher::Create to return an llvm::Expected. Adjust the Windows stub accordingly. (upstreamed from github.com/apple/swift-clang) llvm-svn: 368762
* [clang] DirectoryWatcher for Windows stubs (to fix build break).Jan Korous2019-08-132-0/+50
| | | | | | | | | This is just a code skeleton for DirectoryWatcher-windows.cpp so the build on Windows stops breaking. (upstreamed from github.com/apple/swift-clang) llvm-svn: 368761
* Attempt to fix issue with unresolved lit test in TableGenJessica Paquette2019-08-131-0/+1
| | | | | | | | Build bots are unhappy about the Common directory. Add an excludes list to lit.local.cfg. llvm-svn: 368760
* Initial support for native debugging of x86/x64 Windows processesAaron Smith2019-08-1325-9/+2916
| | | | | | | | | | | | | | | | Summary: Thanks to Hui Huang and the reviewers for all the help with this patch. Reviewers: labath, Hui, jfb, clayborg, amccarth Reviewed By: labath Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D63165 llvm-svn: 368759
* [NFCI] Explicitly provide user-defined constructor for SectionRefAlex Langford2019-08-131-1/+1
| | | | | | | | | I am changing this to work around an issue that is being hit when building with clang 3.8. Specifically, clang 3.8 requires that we have a user defined default constructor for SectionRef for the default initialization of a const SectionRef. llvm-svn: 368758
* [GlobalISel][NFC] Factor out common target code from GlobalISelEmitterTestsJessica Paquette2019-08-134-47/+26
| | | | | | | | | | | | Factor out commonly-used target code from the GlobalISelEmitter tests into a GlobalISelEmitterCommon.td file. This is tested by the original GlobalISelEmitter.td test. This reduces the amount of boilerplate code necessary for tests like this. Differential Revision: https://reviews.llvm.org/D65777 llvm-svn: 368757
* Relax opcode checks in test to check for only a number instead of a specific ↵Douglas Yung2019-08-131-5/+5
| | | | | | number. llvm-svn: 368756
* [analyzer][NFC] Make sure that the BugReport is not modified during the ↵Kristof Umann2019-08-135-18/+28
| | | | | | | | | | | | construction of non-visitor pieces I feel this is kinda important, because in a followup patch I'm adding different kinds of interestingness, and propagating the correct kind in BugReporter.cpp is just one less thing to worry about. Differential Revision: https://reviews.llvm.org/D65578 llvm-svn: 368755
* Add a missing header comment, NFCErik Pilkington2019-08-131-0/+13
| | | | llvm-svn: 368754
* [GlobalISel]: Fix lowering of G_SHUFFLE_VECTOR with scalar sourcesAditya Nandakumar2019-08-133-5/+34
| | | | | | https://reviews.llvm.org/D66171 llvm-svn: 368753
* [analyzer][NFC] Refactoring BugReporter.cpp P6.: Completely get rid of ↵Kristof Umann2019-08-131-97/+0
| | | | | | | | | | | | | | | | interestingness propagation Apparently this does literally nothing. When you think about this, it makes sense. If something is really important, we're tracking it anyways, and that system is sophisticated enough to mark actually interesting statements as such. I wouldn't say that it's even likely that subexpressions are also interesting (array[10 - x + x]), so I guess even if this produced any effects, its probably undesirable. Differential Revision: https://reviews.llvm.org/D65487 llvm-svn: 368752
* Factor architecture dependent code out of loop.cuJon Chesterfield2019-08-132-9/+49
| | | | | | | | | | | | | | | | | | | | | Summary: [libomptarget] Factor architecture dependent code out of loop.cu Related to the patch series starting D64217. Added subscribers to said series as reviewers. This effort is smaller in scope. This patch factors out just enough architecture dependent code from loop.cu to allow the same source to be used with amdgcn, given a different target_impl.h. Testing is that the same bitcode (modulo variable names) is generated for libomptarget before and after the refactor, for nvptx and the out of tree amdgcn. Reviewers: jdoerfert, ABataev, bollu, jfb, tra, grokos, Hahnfeld, guansong, xtian, gregrodgers, ronlieb, hfinkel, gtbercea, guraypp, arpith-jacob Reviewed By: jdoerfert, ABataev Subscribers: dexonsmith, openmp-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D65836 llvm-svn: 368751
* [WebAssembly] Make clang emit correct va_arg code for structsGuanzhong Chen2019-08-132-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In the WebAssembly backend, when lowering variadic function calls, non-single member aggregate type arguments are always passed by pointer. However, when emitting va_arg code in clang, the arguments are instead read as if they are passed directly. This results in the pointer being read as the actual structure. Fixes https://github.com/emscripten-core/emscripten/issues/9042. Reviewers: tlively, sbc100, kripken, aheejin, dschuff Reviewed By: dschuff Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66168 llvm-svn: 368750
* [libc++] Mark two <chrono> tests as unsupported on AppleClang 11Louis Dionne2019-08-132-2/+2
| | | | | | | The operator""y and operator""d will eventually be supported by AppleClang, but no released version supports them at the moment. llvm-svn: 368749
* Remove the extra `;`.Michael Liao2019-08-131-1/+1
| | | | llvm-svn: 368748
* [GISel] Pass MachineRegisterInfo by const reference to matcher.Mark Lacey2019-08-131-9/+11
| | | | | | | | | | | | | | Summary: NFC. Reviewers: aditya_nandakumar, volkan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65971 llvm-svn: 368747
* [DWARF] Guess the path styleJonas Devlieghere2019-08-131-2/+6
| | | | | | Try to guess the FileSpec path style before defaulting to native. llvm-svn: 368746
* [analyzer][NFC] Address inlines of D65484Kristof Umann2019-08-131-37/+38
| | | | llvm-svn: 368745
* [AIX]Lowering global address for 32/64bit small/large code modelsXiangling Liao2019-08-138-46/+195
| | | | | | | | | | | | This patch implements global address lowering for 32/64 bit with small/large code models. 1.For 32bit large code model on AIX, there are newly added pseudo opcode LWZtocL & ADDIStocHA32, the support of which on MC layer will be provided by future patches. 2.The default code model on AIX should be small code model. 3.Since AIX does not have medium code model, "report_fatal_error" when users specify it. Differential Revision: https://reviews.llvm.org/D63547 llvm-svn: 368744
* [Refactor] Moving SourceExtraction header from lib to includeShaurya Gupta2019-08-133-5/+5
| | | | | | | | | | | | | | | Summary: - Moved the SourceExtraction header from lib to include so that it can be used in clangd. Reviewers: arphaman Subscribers: ilya-biryukov, dexonsmith, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65878 llvm-svn: 368743
* [DWARF} Use LLVM's debug line parser in LLDB.Jonas Devlieghere2019-08-137-1210/+187
| | | | | | | | | | | | | | | | The line number table header was substantially revised in DWARF 5 and is not fully supported by LLDB's current debug line implementation. This patch replaces the LLDB debug line parser with its counterpart in LLVM. This was possible because of the limited contact surface between the code to parse the DWARF debug line section and the rest of LLDB. We pay a small cost in terms of performance and memory usage. This is something we plan to address in the near future. Differential revision: https://reviews.llvm.org/D62570 llvm-svn: 368742
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-1311-494/+584
| | | | | | | | | | Summary: Ideally CompilerType would have no knowledge of clang or any individual TypeSystem. Decoupling clang is relatively straightforward. Differential Revision: https://reviews.llvm.org/D66102 llvm-svn: 368741
* [ORC] Fix BuildingAJIT tutorial code broken by r368707.Lang Hames2019-08-132-2/+2
| | | | llvm-svn: 368740
* Don't use std::errcAlexey Bataev2019-08-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As noted on Errc.h: // * std::errc is just marked with is_error_condition_enum. This means that // common patters like AnErrorCode == errc::no_such_file_or_directory take // 4 virtual calls instead of two comparisons. And on some libstdc++ those virtual functions conclude that ------------------------ int main() { std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory); return foo == std::errc::no_such_file_or_directory; } ------------------------- should exit with 0. Reviewers: thakis, rnk, jfb Reviewed By: thakis Subscribers: lebedev.ri, dexonsmith, xbolva00, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D66143 llvm-svn: 368739
* Revert "Fix crash on switch conditions of non-integer types in templates"Dmitri Gribenko2019-08-136-27/+6
| | | | | | This reverts commit r368706. It broke ClangTidy tests. llvm-svn: 368738
* [analyzer][NFC] Refactoring BugReporter.cpp P5.: Compact mile long function ↵Kristof Umann2019-08-134-379/+459
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | invocations into objects In D65379, I briefly described the construction of bug paths from an ExplodedGraph. This patch is about refactoring the code processing the bug path into a bug report. A part of finding a valid bug report was running all visitors on the bug path, so we already have a (possibly empty) set of diagnostics for each ExplodedNode in it. Then, for each diagnostic consumer, we construct non-visitor diagnostic pieces. * We first construct the final diagnostic piece (the warning), then * We start ascending the bug path from the error node's predecessor (since the error node itself was used to construct the warning event). For each node * We check the location (whether its a CallEnter, CallExit) etc. We simultaneously keep track of where we are with the execution by pushing CallStack when we see a CallExit (keep in mind that everything is happening in reverse!), popping it when we find a CallEnter, compacting them into a single PathDiagnosticCallEvent. void f() { bar(); } void g() { f(); error(); // warning } === The bug path === (root) -> f's CallEnter -> bar() -> f's CallExit -> (error node) === Constructed report === f's CallEnter -> bar() -> f's CallExit ^ / \ V (root) ---> f's CallEvent --> (error node) * We also keep track of different PathPieces different location contexts * (CallEvent::path in the above example has f's LocationContext, while the CallEvent itself is in g's context) in a LocationContextMap object. Construct whatever piece, if any, is needed for the note. * If we need to generate edges (or arrows) do so. Make sure to also connect these pieces with the ones that visitors emitted. * Clean up the constructed PathDiagnostic by making arrows nicer, pruning function calls, etc. So I complained about mile long function invocations with seemingly the same parameters being passed around. This problem, as I see it, a natural candidate for creating classes and tying them all together. I tried very hard to make the implementation feel natural, like, rolling off the tongue. I introduced 2 new classes: PathDiagnosticBuilder (I mean, I kept the name but changed almost everything in it) contains every contextual information (owns the bug path, the diagnostics constructed but the visitors, the BugReport itself, etc) needed for constructing a PathDiagnostic object, and is pretty much completely immutable. BugReportContruct is the object containing every non-contextual information (the PathDiagnostic object we're constructing, the current location in the bug path, the location context map and the call stack I meantioned earlier), and is passed around all over the place as a single entity instead of who knows how many parameters. I tried to used constness, asserts, limiting visibility of fields to my advantage to clean up the code big time and dramatically improve safety. Also, whenever I found the code difficult to understand, I added comments and/or examples. Here's a complete list of changes and my design philosophy behind it: * Instead of construcing a ReportInfo object (added by D65379) after finding a valid bug report, simply return an optional PathDiagnosticBuilder object straight away. Move findValidReport into the class as a static method. I find GRBugReporter::generatePathDiagnostics a joy to look at now. * Rename generatePathDiagnosticForConsumer to generate (maybe not needed, but felt that way in the moment) and moved it to PathDiagnosticBuilder. If we don't need to generate diagnostics, bail out straight away, like we always should have. After that, construct a BugReportConstruct object, leaving the rest of the logic untouched. * Move all static methods that would use contextual information into PathDiagnosticBuilder, reduce their parameter count drastically by simply passing around a BugReportConstruct object. * Glance at the code I removed: Could you tell what the original PathDiagnosticBuilder::LC object was for? It took a gooood long while for me to realize that nothing really. It is always equal with the LocationContext associated with our current position in the bug path. Remove it completely. * The original code contains the following expression quite a bit: LCM[&PD.getActivePath()], so what does it mean? I said that we collect the contexts associated with different PathPieces, but why would we ever modify that, shouldn't it be set? Well, theoretically yes, but in the implementation, the address of PathDiagnostic::getActivePath doesn't change if we move to an outer, previously unexplored function. Add both descriptive method names and explanations to BugReportConstruct to help on this. * Add plenty of asserts, both for safety and as a poor man's documentation. Differential Revision: https://reviews.llvm.org/D65484 llvm-svn: 368737
* [AMDGPU] Fix to 'Fold readlane from copy of SGPR or imm'Tim Renouf2019-08-132-2/+5
| | | | | | | | | That change (r363670) could leave a copy from vgpr to sgpr. Fixed. Differential Revision: https://reviews.llvm.org/D66133 Change-Id: I00c3fe6fda2e8e1e36f53195b881b1449c777ea4 llvm-svn: 368736
* [analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it ↵Kristof Umann2019-08-1315-98/+110
| | | | | | | | | | | | | | const When I'm new to a file/codebase, I personally find C++'s strong static type system to be a great aid. BugReporter.cpp is still painful to read however: function calls are made with mile long parameter lists, seemingly all of them taken with a non-const reference/pointer. This patch fixes nothing but this: make a few things const, and hammer it until it compiles. Differential Revision: https://reviews.llvm.org/D65382 llvm-svn: 368735
* [NFC][clang] Adding argument based Phase list filtering to getComplicationPhasesPuyan Lotfi2019-08-133-10/+67
| | | | | | | | | | This patch removes usage of FinalPhase from anywhere outside of the scope where it is used to do argument handling. It also adds argument based trimming of the Phase list pulled out of the Types.def table. Differential Revision: https://reviews.llvm.org/D65993 llvm-svn: 368734
* [ARM] Add MVE beats vector cost modelDavid Green2019-08-1311-686/+1066
| | | | | | | | | | | | | | | | | | | | | | | | The MVE architecture has the idea of "beats", where a vector instruction can be executed over several ticks of the architecture. This adds a similar system into the Arm backend cost model, multiplying the cost of all vector instructions by a factor. This factor essentially becomes the expected difference between scalar code and vector code, on average. MVE Vector instructions can also overlap so the a true cost of them is often lower. But equally scalar instructions can in some situations be dual issued, or have other optimisations such as unrolling or make use of dsp instructions. The default is chosen as 2. This should not prevent vectorisation is a most cases (as the vector instructions will still be doing at least 4 times the work), but it will help prevent over vectorising in cases where the benefits are less likely. This adds things so far to the obvious places in ARMTargetTransformInfo, and updates a few related costs like not treating float instructions as cost 2 just because they are floats. Differential Revision: https://reviews.llvm.org/D66005 llvm-svn: 368733
* [clang] Refactor doc comments to Decls attributionJan Korous2019-08-138-278/+355
| | | | | | | | | | | | - Create ASTContext::attachCommentsToJustParsedDecls so we don't have to load external comments in Sema when trying to attach existing comments to just parsed Decls. - Keep comments ordered and cache their decomposed location - faster SourceLoc-based searching. - Optimize work with redeclarations. - Keep one comment per redeclaration chain (represented by canonical Decl) instead of comment per redeclaration. - For redeclaration chains with no comment attached keep just the last declaration in chain that had no comment instead of every comment-less redeclaration. Differential Revision: https://reviews.llvm.org/D65301 llvm-svn: 368732
* [llvm-profdata] Profile dump for compact binary formatWenlei He2019-08-134-6/+29
| | | | | | | | | | | | | | Summary: Fix "llvm-profdata show" so it can work with compact binary format profile. The change is to mark all functions "used" so SampleProfileReaderCompactBinary::read will read in all profiles available for dumping. The function names will be MD5 hash for compact binary format. Reviewers: wmi, davidxl, danielcdh Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65162 llvm-svn: 368731
* [AutoUpgrader] Make ArcRuntime Autoupgrader more conservativeSteven Wu2019-08-135-48/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a tweak to r368311 and r368646 which auto upgrades the calls to objc runtime functions to objc runtime intrinsics, in order to make sure that the auto upgrader does not trigger with up-to-date bitcode. It is possible for bitcode that is up-to-date to contain direct calls to objc runtime function and those are not inserted by compiler as part of ARC and they should not be upgraded. Now auto upgrader only triggers as when the old style of ARC marker is used so it is guaranteed that it won't trigger on update-to-date bitcode. This also means it won't do this upgrade for bitcode from llvm-8 and llvm-9, which preserves the behavior of those releases. Ideally they should be upgraded as well but it is more important to make sure AutoUpgrader will not trigger on up-to-date bitcode. Reviewers: ahatanak, rjmccall, dexonsmith, pete Reviewed By: dexonsmith Subscribers: hiraditya, jkorous, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66153 llvm-svn: 368730
* [NFC] Fixed testDavid Bolvansky2019-08-131-1/+1
| | | | llvm-svn: 368729
OpenPOWER on IntegriCloud