summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Verifier.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [TBAAVerifier] Make things const-consistent; NFCSanjoy Das2016-12-291-6/+6
| | | | llvm-svn: 290712
* [TBAAVerifier] Memoize validity of scalar tbaa nodes; NFCISanjoy Das2016-12-291-5/+14
| | | | llvm-svn: 290711
* Introduce element-wise atomic memcpy intrinsicIgor Laevsky2016-12-291-0/+26
| | | | | | | | | | This change adds a new intrinsic which is intended to provide memcpy functionality with additional atomicity guarantees. Please refer to the review thread or language reference for further details. Differential Revision: https://reviews.llvm.org/D27133 llvm-svn: 290708
* [DebugInfo] Added support for Checksum debug info feature.Amjad Aboud2016-12-251-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D27642 llvm-svn: 290514
* Refactor the DIExpression fragment query interface (NFC)Adrian Prantl2016-12-221-3/+4
| | | | | | ... so it becomes available to DIExpressionCursor. llvm-svn: 290322
* Reapply r289926: attempt to fix windows buildAdrian Prantl2016-12-201-1/+2
| | | | llvm-svn: 290158
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-201-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-21/+5
| | | | | | | | | | | | | | | | | 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
* Move VerifierSupport into namespace llvm.Daniel Jasper2016-12-161-1/+5
| | | | | | | | | It currently is in an unnamed namespace and then it shouldn't be used from something in the header file. This actually triggers a warning with GCC: ../include/llvm/IR/Verifier.h:39:7: warning: ‘llvm::TBAAVerifier’ has a field ‘llvm::TBAAVerifier::Diagnostic’ whose type uses the anonymous namespace [enabled by default] llvm-svn: 289942
* Extract a TBAAVerifier out of the verifier (NFC)Mehdi Amini2016-12-161-268/+268
| | | | | | | | | | | This is intended to be used (in a later patch) by the BitcodeReader to detect invalid TBAA and drop them when loading bitcode, so that we don't break client that have legacy bitcode with possible invalid TBAA. Differential Revision: https://reviews.llvm.org/D27838 llvm-svn: 289927
* attempt to fix windows buildNico Weber2016-12-161-1/+2
| | | | llvm-svn: 289926
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-21/+5
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Verifier] Allow TBAA metadata on atomicrmw and atomiccmpxchgSanjoy Das2016-12-151-1/+2
| | | | | | | | | This used to be allowed before r289402 by default (before r289402 you could have TBAA metadata on any instruction), and while I'm not sure that it helps, it does sound reasonable enough to not fail the verifier and we have out-of-tree users who use this. llvm-svn: 289872
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | 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
* [Verifier] Add verification for TBAA metadataSanjoy Das2016-12-111-2/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PM] Change the static object whose address is used to uniquely identifyChandler Carruth2016-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
* [Verifier] clang-format a section; NFCSanjoy Das2016-11-091-6/+4
| | | | | | Suggested in D26438 since I'm touching related code. llvm-svn: 286388
* [TBAA] Drop support for "old style" scalar TBAA tagsSanjoy Das2016-11-081-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had support for auto upgrading old style scalar TBAA access metadata tags into the "new" struct path aware TBAA metadata for 3 years now. The only way to actually generate old style TBAA was explicitly through the IRBuilder API. I think this is a good time for dropping support for old style scalar TBAA. I'm not removing support for textual or bitcode upgrade -- if you have IR with the old style scalar TBAA tags that go through the AsmParser orf the bitcode parser before LLVM sees them, they will keep working as usual. Note: %val = load i32, i32* %ptr, !tbaa !N !N = < scalar tbaa node > is equivalent to %val = load i32, i32* %ptr, !tbaa !M !N = < scalar tbaa node > !M = !{!N, !N, 0} Reviewers: manmanren, chandlerc, sunfish Subscribers: mcrosier, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D26229 llvm-svn: 286291
* DebugInfo: make DW_TAG_atomic_type validVictor Leschuk2016-10-311-0/+1
| | | | | | | | | | | | | | DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly, however Verifier didn't recognize it as valid. Thus we introduce the following changes: * Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5) * Add it to related docs * Add DebugInfo tests Differential Revision: https://reviews.llvm.org/D26144 llvm-svn: 285624
* Verifier: Reject any unknown named MD nodes in the llvm.dbg namespace.Adrian Prantl2016-10-051-2/+7
| | | | | | | | | | | | | This came out of a discussion in https://reviews.llvm.org/D25285. There used to be various other llvm.dbg.* nodes, but we don't support upgrading them and we want to reserve the namespace for future uses. This also removes an entirely obsolete and bitrotted testcase for PR7662. Reapplies 283390 with a forgotten testcase. llvm-svn: 283400
* Revert "Verifier: Reject any unknown named MD nodes in the llvm.dbg namespace."Adrian Prantl2016-10-051-7/+2
| | | | | | Forgot to add a testcase in r283390. llvm-svn: 283399
* Verifier: Reject any unknown named MD nodes in the llvm.dbg namespace.Adrian Prantl2016-10-051-2/+7
| | | | | | | | | | | This came out of a discussion in https://reviews.llvm.org/D25285. There used to be various other llvm.dbg.* nodes, but we don't support upgrading them and we want to reserve the namespace for future uses. This also removes an entirely obsolete and bitrotted testcase for PR7662. llvm-svn: 283390
* Verifier: Mark orphaned DICompileUnits as a debug info failure.Adrian Prantl2016-09-141-10/+10
| | | | | | | | | This is a follow-up to r268778 that adds a couple of missing cases, most notably orphaned compile units. rdar://problem/28193346 llvm-svn: 281508
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-6/+2
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* It should also be legal to pass a swifterror parameter to a call as a swifterrorArnold Schwaighofer2016-09-101-4/+9
| | | | | | | | argument. rdar://28233388 llvm-svn: 281147
* ADT: Remove external uses of ilist_iterator, NFCDuncan P. N. Exon Smith2016-09-031-4/+0
| | | | | | | | | | | | Delete the dead code for Write(ilist_iterator) in the IR Verifier, inline report(ilist_iterator) at its call sites in the MachineVerifier, and use simple_ilist<>::iterator in SymbolTableListTraits. The only remaining reference to ilist_iterator outside of the ilist implementation is from MachineInstrBundleIterator. I'll get rid of that in a follow-up. llvm-svn: 280565
* [Coroutines] Part 9: Add cleanup subfunction.Gor Nishanov2016-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: [Coroutines] Part 9: Add cleanup subfunction. This patch completes coroutine heap allocation elision. Now, the heap elision example from docs\Coroutines.rst compiles and produces expected result (see test/Transform/Coroutines/ex3.ll) Intrinsic Changes: * coro.free gets a token parameter tying it to coro.id to allow reliably discovering all coro.frees associated with a particular coroutine. * coro.id gets an extra parameter that points back to a coroutine function. This allows to check whether a coro.id describes the enclosing function or it belongs to a different function that was later inlined. CoroSplit now creates three subfunctions: # f$resume - resume logic # f$destroy - cleanup logic, followed by a deallocation code # f$cleanup - just the cleanup code CoroElide pass during devirtualization replaces coro.destroy with either f$destroy or f$cleanup depending whether heap elision is performed or not. Other fixes, improvements: * Fixed buglet in Shape::buildFrame that was not creating coro.save properly if coroutine has more than one suspend point. * Switched to using variable width suspend index field (no longer limited to 32 bit index field can be as little as i1 or as large as i<whatever-size_t-is>) Reviewers: majnemer Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23844 llvm-svn: 279971
* fix typo 'varaible' in assertNico Weber2016-08-241-1/+1
| | | | llvm-svn: 279636
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings.Eugene Zelenko2016-08-131-13/+52
| | | | | | Differential revision: https://reviews.llvm.org/D23478 llvm-svn: 278583
* [Coroutines]: Part6b: Add coro.id intrinsic.Gor Nishanov2016-08-121-2/+2
| | | | | | | | | | | | | | | Summary: 1. Make coroutine representation more robust against optimization that may duplicate instruction by introducing coro.id intrinsics that returns a token that will get fed into coro.alloc and coro.begin. Due to coro.id returning a token, it won't get duplicated and can be used as reliable indicator of coroutine identify when a particular coroutine call gets inlined. 2. Move last three arguments of coro.begin into coro.id as they will be shared if coro.begin will get duplicated. 3. doc + test + code updated to support the new intrinsic. Reviewers: mehdi_amini, majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23412 llvm-svn: 278481
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-2/+2
| | | | | | No functionality change is intended. llvm-svn: 278417
* [Statepoints] Minor cosmetic change; NFCSanjoy Das2016-08-111-1/+1
| | | | | | The verification failure message was missing a space. llvm-svn: 278309
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-061-5/+3
| | | | llvm-svn: 277916
* Part 4c: Coroutine Devirtualization: Devirtualize coro.resume and coro.destroy.Gor Nishanov2016-08-061-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the 4c patch of the coroutine series. CoroElide pass now checks if PostSplit coro.begin is referenced by coro.subfn.addr intrinsics. If so replace coro.subfn.addrs with an appropriate coroutine subfunction associated with that coro.begin. Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) 3.Add empty coroutine passes. (https://reviews.llvm.org/D22847) 4.Add coroutine devirtualization + tests. ab) Lower coro.resume and coro.destroy (https://reviews.llvm.org/D22998) c) Do devirtualization <= we are here 5.Add CGSCC restart trigger + tests. 6.Add coroutine heap elision + tests. 7.Add the rest of the logic (split into more patches) Reviewers: majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23229 llvm-svn: 277908
* [coroutines] Part 4[ab]: Coroutine Devirtualization: Lower coro.resume and ↵David Majnemer2016-08-041-2/+4
| | | | | | | | | | | | | | | | coro.destroy. This is the forth patch in the coroutine series. CoroEaly pass now lowers coro.resume and coro.destroy intrinsics by replacing them with an indirect call to an address returned by coro.subfn.addr intrinsic. This is done so that CGPassManager recognizes devirtualization when CoroElide replaces a call to coro.subfn.addr with an appropriate function address. Patch by Gor Nishanov! Differential Revision: https://reviews.llvm.org/D22998 llvm-svn: 277765
* [Verifier] Disallow illegal ptr<->int casts in ConstantExprsSanjoy Das2016-08-021-8/+22
| | | | | | | This should have been a part of rL277085, but I hadn't considered this case. llvm-svn: 277413
* Tie the Verifier class to a Module; NFCISanjoy Das2016-08-021-72/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit changes the Verifier class to accept a Module via the constructor to make it obvious that a specific instance of the class is only intended to work with a specific module. The `updateModule` setter (despite being private) was making this fact less transparent. There are fields in the `Verifier` class like `DeoptimizeDeclarations` and `GlobalValueVisited` which are module specific, so a given Verifier instance will not in fact work across multiple modules today. This change just makes that more obvious. The motivation is to make it easy to get to the datalayout of the module unambiguously. That is required to verify that `inttoptr` and `ptrtoint` constant expressions are well typed in the face of non-integral pointer types. Reviewers: dexonsmith, bkramer, majnemer, chandlerc Subscribers: mehdi_amini, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23040 llvm-svn: 277409
* [Verifier] Resume instructions can only be in functions w/ a personalityDavid Majnemer2016-08-011-0/+16
| | | | | | This fixes PR28799. llvm-svn: 277360
* Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942.Justin Lebar2016-07-281-1/+1
| | | | | | | | | This broke some out-of-tree AMDGPU tests that relied on the old behavior wherein isIntrinsic() would return true for any function that starts with "llvm.". And in general that change will not play nicely with out-of-tree backends. llvm-svn: 277087
* [IR] Introduce a non-integral pointer typeSanjoy Das2016-07-281-0/+10
| | | | | | | | | | | | | | | Summary: This change adds a `ni` specifier in the `datalayout` string to denote pointers in some given address spaces as "non-integral", and adds some typing rules around these special pointers. Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm Subscribers: arsenm, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D22488 llvm-svn: 277085
* Don't invoke getName() from Function::isIntrinsic().Justin Lebar2016-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: getName() involves a hashtable lookup, so is expensive given how frequently isIntrinsic() is called. (In particular, many users cast to IntrinsicInstr or one of its subclasses before calling getIntrinsicID().) This has an incidental functional change: Before, isIntrinsic() would return true for any function whose name started with "llvm.", even if it wasn't properly an intrinsic. The new behavior seems more correct to me, because it's strange to say that isIntrinsic() is true, but getIntrinsicId() returns "not an intrinsic". Some callers want the old behavior -- they want to know whether the caller is a recognized intrinsic, or might be one in some other version of LLVM. For them, we added Function::hasLLVMReservedName(), which checks whether the name starts with "llvm.". This change is good for a 1.5% e2e speedup compiling a large Eigen benchmark. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22065 llvm-svn: 276942
* Add writeonly IR attributeNicolai Haehnle2016-07-041-0/+23
| | | | | | | | | | | | | | | | | Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
* Verifier: Reject non-float !fpmathMatt Arsenault2016-06-271-0/+2
| | | | | | | Code already assumes this is float. getFPAccuracy() crashes on any other type. llvm-svn: 273912
* NFC. Move verifyIntrinsicIsVarArg from verifier to ↵Artur Pilipenko2016-06-241-30/+2
| | | | | | Intrinsic::matchIntrinsicVarArg since it will be reused for intrinsic remangling code llvm-svn: 273685
* NFC. Move Verifier::verifyIntrinsicType to Intrinsics.hArtur Pilipenko2016-06-221-148/+4
| | | | | | | | | | Move Verifier::verifyIntrinsicType to Intrinsics::matchIntrinsicsType. Will be used to accumulate overloaded types of a given intrinsic by the upcoming patch to fix intrinsics names when overloaded types are renamed. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D19372 llvm-svn: 273424
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-211-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
* [PM] Remove support for omitting the AnalysisManager argument to newChandler Carruth2016-06-171-2/+4
| | | | | | | | | | | | | | | | | | | | pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
OpenPOWER on IntegriCloud