summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-194-4/+15
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* [PDB] Validate superblock addressesDavid Majnemer2016-12-181-0/+1
| | | | | | | - Validate the address of the block map. - Validate the address of the free block map. llvm-svn: 290053
* Fix compilation.Evgeniy Stepanov2016-12-171-1/+1
| | | | | | | unittests/ADT/TwineTest.cpp:106:38: error: field 'Count' will be initialized after base 'llvm::FormatAdapter<int>' [-Werror,-Wreorder] explicit formatter(int &Count) : Count(Count), FormatAdapter(0) {} llvm-svn: 290029
* Retry: [BPI] Use a safer constructor to calculate branch probabilitiesVedant Kumar2016-12-172-0/+89
| | | | | | | | | | | | | | | | | | | BPI may trigger signed overflow UB while computing branch probabilities for cold calls or to unreachables. For example, with our current choice of weights, we'll crash if there are >= 2^12 branches to an unreachable. Use a safer BranchProbability constructor which is better at handling fractions with large denominators. Changes since the initial commit: - Use explicit casts to ensure that multiplication operands are 64-bit ints. rdar://problem/29368161 Differential Revision: https://reviews.llvm.org/D27862 llvm-svn: 290022
* Add support for formatv to llvm::Twine.Zachary Turner2016-12-171-1/+27
| | | | | | Differential Revision: https://reviews.llvm.org/D27835 llvm-svn: 290020
* Revert "[BPI] Use a safer constructor to calculate branch probabilities"Vedant Kumar2016-12-172-89/+0
| | | | | | | | | | This reverts commit r290016. It breaks this bot, even though the test passes locally: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/32956/ AnalysisTests: /home/bb/ninja-x64-msvc-RA-centos6/llvm-project/llvm/lib/Support/BranchProbability.cpp:52: static llvm::BranchProbability llvm::BranchProbability::getBranchProbability(uint64_t, uint64_t): Assertion `Numerator <= Denominator && "Probability cannot be bigger than 1!"' failed. llvm-svn: 290019
* [BPI] Use a safer constructor to calculate branch probabilitiesVedant Kumar2016-12-172-0/+89
| | | | | | | | | | | | | | | BPI may trigger signed overflow UB while computing branch probabilities for cold calls or to unreachables. For example, with our current choice of weights, we'll crash if there are >= 2^12 branches to an unreachable. Use a safer BranchProbability constructor which is better at handling fractions with large denominators. rdar://problem/29368161 Differential Revision: https://reviews.llvm.org/D27862 llvm-svn: 290016
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-49/+32
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-32/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-49/+32
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [APFloatTest] Log when test fails. NFCTim Shen2016-12-161-7/+21
| | | | | | | | | | Reviewers: iteratee Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27828 llvm-svn: 289904
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-32/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* Simplify format member detection in FormatVariadicPavel Labath2016-12-151-39/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the format member search, which was quite complicated, with a more direct approach to detecting whether a class should be formatted using the format-member method. Instead we use a special type llvm::format_adapter, which every adapter must inherit from. Then the search can be simply implemented with the is_base_of type trait. Aside from the simplification, I like this way more because it makes it more explicit that you are supposed to use this type only for adapter-like formattings, and the other approach (format_provider overloads) should be used as a default (a mistake I made when first trying to use this library). The only slight change in behaviour here is that now choose the format-adapter branch even if the format member invocation will fail to compile (e.g. because it is a non-const member function and we are passing a const adapter), whereas previously we would have gone on to search for format_providers for the type. However, I think that is actually a good thing, as it probably means the programmer did something wrong. Reviewers: zturner, inglorion Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27679 llvm-svn: 289795
* Remove the AssumptionCacheHal Finkel2016-12-154-15/+4
| | | | | | | | | After r289755, the AssumptionCache is no longer needed. Variables affected by assumptions are now found by using the new operand-bundle-based scheme. This new scheme is more computationally efficient, and also we need much less code... llvm-svn: 289756
* [DebugInfo] Changed DIBuilder::createCompileUnit() to take DIFile instead of ↵Amjad Aboud2016-12-143-17/+24
| | | | | | | | | | | | FileName and Directory. This way it will be easier to expand DIFile (e.g., to contain checksum) without the need to modify the createCompileUnit() API. Reviewers: llvm-commits, rnk Differential Revision: https://reviews.llvm.org/D27762 llvm-svn: 289702
* Adapt to recent APFloat changeStephan Bergmann2016-12-141-6/+6
| | | | llvm-svn: 289649
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-820/+820
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [llvm] Iterate SmallPtrSet in reverse order to uncover non-determinism in ↵Mandeep Singh Grang2016-12-142-0/+40
| | | | | | | | | | | | | | | | | | codegen Summary: Given a flag (-mllvm -reverse-iterate) this patch will enable iteration of SmallPtrSet in reverse order. The idea is to compile the same source with and without this flag and expect the code to not change. If there is a difference in codegen then it would mean that the codegen is sensitive to the iteration order of SmallPtrSet. This is enabled only with LLVM_ENABLE_ABI_BREAKING_CHECKS. Reviewers: chandlerc, dexonsmith, mehdi_amini Subscribers: mgorny, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D26718 llvm-svn: 289619
* Add support for Samsung Exynos M3 (NFC)Evandro Menezes2016-12-131-0/+8
| | | | llvm-svn: 289613
* Switch functions that returned bool and filled in a DWARFFormValue arg with ↵Greg Clayton2016-12-131-9/+13
| | | | | | | | ones that return Optional<DWARFFormValue> Differential Revision: https://reviews.llvm.org/D27737 llvm-svn: 289611
* Make a DWARFDIE class that can help avoid using the wrong DWARFUnit when ↵Greg Clayton2016-12-132-131/+130
| | | | | | | | | | | | extracting attributes Many places pass around a DWARFDebugInfoEntryMinimal and a DWARFUnit. It is easy to get things wrong by using the wrong DWARFUnit with a DWARFDebugInfoEntryMinimal. This patch creates a DWARFDie class that contains the DWARFUnit and DWARFDebugInfoEntryMinimal objects so that they can't get out of sync. All attribute extraction has been moved out of DWARFDebugInfoEntryMinimal and into DWARFDie. DWARFDebugInfoEntryMinimal was also renamed to DWARFDebugInfoEntry. DWARFDie objects are temporary objects that are used by clients and contain 2 pointers that you always need to have anyway. Keeping them grouped will avoid errors and simplify many of the attribute extracting APIs by not having to pass in a DWARFUnit. Differential Revision: https://reviews.llvm.org/D27634 llvm-svn: 289565
* [ADT] Add llvm::StringLiteral.Zachary Turner2016-12-131-0/+6
| | | | | | | | | | | StringLiteral is a wrapper around a string literal useful for replacing global tables of char arrays with global tables of StringRefs that can initialized in a constexpr context, avoiding the invocation of a global constructor. Differential Revision: https://reviews.llvm.org/D27686 llvm-svn: 289551
* [APFloatTest] Use std::make_tuple to make GCC 4.8 happyTim Shen2016-12-121-35/+38
| | | | | | Differential Revision: https://reviews.llvm.org/D26817 llvm-svn: 289474
* [APFloat] Implement PPCDoubleDouble add and subtract.Tim Shen2016-12-121-16/+119
| | | | | | | | | | | | Summary: I looked at libgcc's implementation (which is based on the paper, Software for Doubled-Precision Floating-Point Computations", by Seppo Linnainmaa, ACM TOMS vol 7 no 3, September 1981, pages 272-283.) and made it generic to arbitrary IEEE floats. Differential Revision: https://reviews.llvm.org/D26817 llvm-svn: 289472
* Revert "[SCEVExpand] do not hoist divisions by zero (PR30935)"Reid Kleckner2016-12-121-108/+4
| | | | | | | | | Reverts r289412. It caused an OOB PHI operand access in instcombine when ASan is enabled. Reduction in progress. Also reverts "[SCEVExpander] Add a test case related to r289412" llvm-svn: 289453
* [SCEVExpander] Add a test case related to r289412Sanjoy Das2016-12-121-5/+33
| | | | llvm-svn: 289435
* [SCEVExpand] do not hoist divisions by zero (PR30935)Sebastian Pop2016-12-121-0/+76
| | | | | | | | | | | | | | | SCEVExpand computes the insertion point for the components of a SCEV to be code generated. When it comes to generating code for a division, SCEVexpand would not be able to check (at compilation time) all the conditions necessary to avoid a division by zero. The patch disables hoisting of expressions containing divisions by anything other than non-zero constants in order to avoid hoisting these expressions past conditions that should hold before doing the division. The patch passes check-all on x86_64-linux. Differential Revision: https://reviews.llvm.org/D27216 llvm-svn: 289412
* [TBAA] Don't generate invalid TBAA when merging nodesSanjoy Das2016-12-111-6/+34
| | | | | | | | | | | | | | Summary: Fix a corner case in `MDNode::getMostGenericTBAA` where we can sometimes generate invalid TBAA metadata. Reviewers: chandlerc, hfinkel, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26635 llvm-svn: 289403
* [PM] Support invalidation of inner analysis managers from a pass over the ↵Chandler Carruth2016-12-102-48/+385
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | outer IR unit. Summary: This never really got implemented, and was very hard to test before a lot of the refactoring changes to make things more robust. But now we can test it thoroughly and cleanly, especially at the CGSCC level. The core idea is that when an inner analysis manager proxy receives the invalidation event for the outer IR unit, it needs to walk the inner IR units and propagate it to the inner analysis manager for each of those units. For example, each function in the SCC needs to get an invalidation event when the SCC gets one. The function / module interaction is somewhat boring here. This really becomes interesting in the face of analysis-backed IR units. This patch effectively handles all of the CGSCC layer's needs -- both invalidating SCC analysis and invalidating function analysis when an SCC gets invalidated. However, this second aspect doesn't really handle the LoopAnalysisManager well at this point. That one will need some change of design in order to fully integrate, because unlike the call graph, the entire function behind a LoopAnalysis's results can vanish out from under us, and we won't even have a cached API to access. I'd like to try to separate solving the loop problems into a subsequent patch though in order to keep this more focused so I've adapted them to the API and updated the tests that immediately fail, but I've not added the level of testing and validation at that layer that I have at the CGSCC layer. An important aspect of this change is that the proxy for the FunctionAnalysisManager at the SCC pass layer doesn't work like the other proxies for an inner IR unit as it doesn't directly manage the FunctionAnalysisManager and invalidation or clearing of it. This would create an ever worsening problem of dual ownership of this responsibility, split between the module-level FAM proxy and this SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy to work in terms of the module-level proxy and defer to it to handle much of the updates. It only does SCC-specific invalidation. This will become more important in subsequent patches that support more complex invalidaiton scenarios. Reviewers: jlebar Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D27197 llvm-svn: 289317
* Plug another leak in the DWARF unittests, DIEInlineStrings are never destroyed.Benjamin Kramer2016-12-091-1/+2
| | | | llvm-svn: 289208
* Fix memory leak in unit test.Benjamin Kramer2016-12-092-3/+3
| | | | | | | The StringPool entries are destroyed with the allocator, the string pool itself is not. llvm-svn: 289207
* Fix ASAN buildbots by fixing a double free crash.Greg Clayton2016-12-082-3/+5
| | | | | | The dwarfgen::Generator::StringPool was in a unique_ptr but it was owned by the Allocator member variable so it was being free twice. llvm-svn: 289070
* DIE::addAttribute(): Prune a redundant \param. [-Wdocumentation]NAKAMURA Takumi2016-12-081-1/+1
| | | | llvm-svn: 289056
* DebugInfoDWARFTests: Prune unused libdeps.NAKAMURA Takumi2016-12-081-4/+0
| | | | llvm-svn: 289053
* DebugInfoDWARFTests: Add missing deps, AsmPrinter and Object.NAKAMURA Takumi2016-12-081-0/+2
| | | | llvm-svn: 289052
* DebugInfoDWARFTests: Reorder LLVM_LINK_COMPONENTS.NAKAMURA Takumi2016-12-081-1/+1
| | | | llvm-svn: 289051
* Move DwarfGenerator.cpp to unittestsDaniel Jasper2016-12-084-1/+495
| | | | | | | | | So far it creates a test helper and so it should be moved there. It also create a layering cycle between CodeGen and CodeGen/AsmPrinter, which should be avoided. Review: https://reviews.llvm.org/D27570 llvm-svn: 289044
* Fix MSCV compilation broken by r289040Pavel Labath2016-12-081-4/+4
| | | | | | | I wanted to use the "not" keyword to make sure it does not get lost in between other checks. MSVC does not like that. llvm-svn: 289041
* Improve format member detection in llvm::formatvPavel Labath2016-12-081-2/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The existing detection of a format member function has a couple of deficiencies: - the member function does not get detected if one calls formatv with an lvalue, because the template parameter gets deduced as T&, which fails the is_class check. - it also did not work if the function was called with a const variable because the template parameter would get deduced as const T&, again failing the is_class check. This fixes the problem by stripping the references in the uses_format_member template, to make sure the type is correctly detected as class. It also provides specializations of the has_FormatMember template for const and non-const members of the types in order to enable declaring the format member as a "const" function. I have added tests that verify that formatv can be now called in these scenarios. As some scenarios could not be verified at runtime (e.g. making sure that calling a non-const format member on a const object does *not* compile), I have also added some static_asserts which test the behaviour of the template classes used internally by formatv(). Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27525 llvm-svn: 289040
* Unbreak buildbots where the debug info test was crashing due to unchecked error.Greg Clayton2016-12-081-4/+5
| | | | llvm-svn: 289017
* Make a DWARF generator so we can unit test DWARF APIs with gtest.Greg Clayton2016-12-082-0/+798
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only tests we have for the DWARF parser are the tests that use llvm-dwarfdump and expect output from textual dumps. More DWARF parser modification are coming in the next few weeks and I wanted to add tests that can verify that we can encode and decode all form types, as well as test some other basic DWARF APIs where we ask DIE objects for their children and siblings. DwarfGenerator.cpp was added in the lib/CodeGen directory. This file contains the code necessary to easily create DWARF for tests: dwarfgen::Generator DG; Triple Triple("x86_64--"); bool success = DG.init(Triple, Version); if (!success) return; dwarfgen::CompileUnit &CU = DG.addCompileUnit(); dwarfgen::DIE CUDie = CU.getUnitDIE(); CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); dwarfgen::DIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); SubprogramDie.addAttribute(DW_AT_high_pc, DW_FORM_addr, 0x2000U); dwarfgen::DIE IntDie = CUDie.addChild(DW_TAG_base_type); IntDie.addAttribute(DW_AT_name, DW_FORM_strp, "int"); IntDie.addAttribute(DW_AT_encoding, DW_FORM_data1, DW_ATE_signed); IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4); dwarfgen::DIE ArgcDie = SubprogramDie.addChild(DW_TAG_formal_parameter); ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); // ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref4, IntDie); ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); StringRef FileBytes = DG.generate(); MemoryBufferRef FileBuffer(FileBytes, "dwarf"); auto Obj = object::ObjectFile::createObjectFile(FileBuffer); EXPECT_TRUE((bool)Obj); DWARFContextInMemory DwarfContext(*Obj.get()); This code is backed by the AsmPrinter code that emits DWARF for the actual compiler. While adding unit tests it was discovered that DIEValue that used DIEEntry as their values had bugs where DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref8, and DW_FORM_ref_udata forms were not supported. These are all now supported. Added support for DW_FORM_string so we can emit inlined C strings. Centralized the code to unique abbreviations into a new DIEAbbrevSet class and made both the dwarfgen::Generator and the llvm::DwarfFile classes use the new class. Fixed comments in the llvm::DIE class so that the Offset is known to be the compile/type unit offset. DIEInteger now supports more DW_FORM values. There are also unit tests that cover: Encoding and decoding all form types and values Encoding and decoding all reference types (DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata, DW_FORM_ref_addr) including cross compile unit references with that go forward one compile unit and backward on compile unit. Differential Revision: https://reviews.llvm.org/D27326 llvm-svn: 289010
* Refactor TargetParserTests.Zijiao Ma2016-12-061-346/+498
| | | | | | | The TargetParser tests are a bit redundant. Refactor them in a more repeatable way. llvm-svn: 288758
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683
* [stl-extras] Provide an adaptor of std::count for ranges.Michael Gottesman2016-12-041-0/+17
| | | | llvm-svn: 288619
* Support escaping in TrigramIndex.Ivan Krasin2016-12-022-2/+33
| | | | | | | | | | | | | | | | | | Summary: This is a follow up to r288303, where I have introduced TrigramIndex to speed up SpecialCaseList for the cases when all rules are simple wildcards, like *hello*wor.d*. Here, I add support for escaping, so that it's possible to specify rules like *c\+\+abi*. Reviewers: pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27318 llvm-svn: 288553
* Use trigrams to speed up SpecialCaseList.Ivan Krasin2016-12-013-0/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: it's often the case when the rules in the SpecialCaseList are of the form hel.o*bar. That gives us a chance to build trigram index to quickly discard 99% of inputs without running a full regex. A similar idea was used in Google Code Search as described in the blog post: https://swtch.com/~rsc/regexp/regexp4.html The check is defeated, if there's at least one regex more complicated than that. In this case, all inputs will go through the regex. That said, the real-world rules are often simple or can be simplied. That considerably speeds up compiling Chromium with CFI and UBSan. As measured on Chromium's content_message_generator.cc: before, CFI: 44 s after, CFI: 23 s after, CFI, no blacklist: 23 s (~1% slower, but 3 runs were unable to show the difference) after, regular compilation to bitcode: 23 s Reviewers: pcc Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D27188 llvm-svn: 288303
* Fix macro check for ABI breacking check: should use #if instead of #ifndefMehdi Amini2016-11-301-10/+10
| | | | llvm-svn: 288265
* Change Error unittest to use the LLVM_ENABLE_ABI_BREAKING_CHECKS instead of ↵Mehdi Amini2016-11-291-10/+10
| | | | | | | | | | NDEBUG This is consistent with the header (after r288087) and fixes the test for the configuration: -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ABI_BREAKING_CHECKS=FORCE_OFF llvm-svn: 288196
* [PM] Extend the explicit 'invalidate' method API on analysis results toChandler Carruth2016-11-282-1/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | accept an Invalidator that allows them to invalidate themselves if their dependencies are in turn invalidated. Rather than recording the dependency graph ahead of time when analysis get results from other analyses, this simply lets each result trigger the immediate invalidation of any analyses they actually depend on. They do this in a way that has three nice properties: 1) They don't have to handle transitive dependencies because the infrastructure will recurse for them. 2) The invalidate methods are still called only once. We just dynamically discover the necessary topological ordering, everything is memoized nicely. 3) The infrastructure still provides a default implementation and can access it so that only analyses which have dependencies need to do anything custom. To make this work at all, the invalidation logic also has to defer the deletion of the result objects themselves so that they can remain alive until we have collected the complete set of results to invalidate. A unittest is added here that has exactly the dependency pattern we are concerned with. It hit the use-after-free described by Sean in much detail in the long thread about analysis invalidation before this change, and even in an intermediate form of this change where we failed to defer the deletion of the result objects. There is an important problem with doing dependency invalidation that *isn't* solved here: we don't *enforce* that results correctly invalidate all the analyses whose results they depend on. I actually looked at what it would take to do that, and it isn't as hard as I had thought but the complexity it introduces seems very likely to outweigh the benefit. The technique would be to provide a base class for an analysis result that would be populated with other results, and automatically provide the invalidate method which immediately does the correct thing. This approach has some nice pros IMO: - Handles the case we care about and nothing else: only *results* that depend on other analyses trigger extra invalidation. - Localized to the result rather than centralized in the analysis manager. - Ties the storage of the reference to another result to the triggering of the invalidation of that analysis. - Still supports extending invalidation in customized ways. But the down sides here are: - Very heavy-weight meta-programming is needed to provide this base class. - Requires a pretty awful API for accessing the dependencies. Ultimately, I fear it will not pull its weight. But we can re-evaluate this at any point if we start discovering consistent problems where the invalidation and dependencies get out of sync. It will fit as a clean layer on top of the facilities in this patch that we can add if and when we need it. Note that I'm not really thrilled with the names for these APIs... The name "Invalidator" seems ok but not great. The method name "invalidate" also. In review some improvements were suggested, but they really need *other* uses of these terms to be updated as well so I'm going to do that in a follow-up commit. I'm working on the actual fixes to various analyses that need to use these, but I want to try to get tests for each of them so we don't regress. And those changes are seperable and obvious so once this goes in I should be able to roll them out throughout LLVM. Many thanks to Sean, Justin, and others for help reviewing here. Differential Revision: https://reviews.llvm.org/D23738 llvm-svn: 288077
* Improve error handling in YAML parsingMehdi Amini2016-11-281-0/+8
| | | | | | | | | | | | Some scanner errors were not checked and reported by the parser. Fix PR30934. Recommit r288014 after fixing unittest. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D26419 llvm-svn: 288071
OpenPOWER on IntegriCloud