summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Verifier.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* Verifier: check that functions have at most a single !prof attachment.Peter Collingbourne2016-06-141-1/+6
| | | | llvm-svn: 272734
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [Verifier] Simplify code. No functionality change intended.Benjamin Kramer2016-06-121-6/+2
| | | | llvm-svn: 272517
* Avoid copies of std::strings and APInt/APFloats where we only read from itBenjamin Kramer2016-06-081-1/+1
| | | | | | | | As suggested by clang-tidy's performance-unnecessary-copy-initialization. This can easily hit lifetime issues, so I audited every change and ran the tests under asan, which came back clean. llvm-svn: 272126
* Verifier: Simplify and fix issue where we were not verifying unmaterialized ↵Peter Collingbourne2016-06-061-15/+13
| | | | | | | | | | | | | | functions. Arrange to call verify(Function &) on each function, followed by verify(Module &), whether the verifier is being used from the pass or from verifyModule(). As a side effect, this fixes an issue that caused us not to call verify(Function &) on unmaterialized functions from verifyModule(). Differential Revision: http://reviews.llvm.org/D21042 llvm-svn: 271956
* Verifier: Remove dead code.Peter Collingbourne2016-06-061-14/+8
| | | | | | | Remove previously unreachable code that verifies that a function definition has an entry block. By definition, a function definition has at least one block. llvm-svn: 271948
* [IR] Disallow loading and storing unsized typesSanjoy Das2016-06-011-0/+2
| | | | | | | | | | | | | | | | Summary: It isn't clear what is the operational meaning of loading or storing an unsized types, since it cannot be lowered into something meaningful. Since there does not seem to be any practical need for it either, make such loads and stores illegal IR. Reviewers: majnemer, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20846 llvm-svn: 271402
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-0/+4
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Port the strip-invalid-debuginfo logic to the legacy verifier pass, too.Adrian Prantl2016-05-251-6/+16
| | | | | | | | | | | | | | | | | | | | | Since r268966 the modern Verifier pass defaults to stripping invalid debug info in nonasserts builds. This patch ports this behavior back to the legacy Verifier pass as well. The primary motivation is that the clang frontend accepts bitcode files as input but is still using the legacy pass pipeline. Background: The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D20629 <rdar://problem/26448800> llvm-svn: 270768
* Appease MSVC with curly bracesSanjoy Das2016-05-121-1/+2
| | | | llvm-svn: 269262
* All llvm.deoptimize declarations must use the same calling conventionSanjoy Das2016-05-121-1/+25
| | | | | | | | | | | | | | | | | This new verifier rule lets us unambigously pick a calling convention when creating a new declaration for `@llvm.experimental.deoptimize.<ty>`. It is also congruent with our lowering strategy -- since all calls to `@llvm.experimental.deoptimize` are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce a unique calling convention. Some of the tests that were breaking this verifier rule have had to be split up into different .ll files. The inliner was violating this rule as well, and has been fixed to avoid producing invalid IR. llvm-svn: 269261
* Refactor duplicated check for valid declaration linkage. NFC.Rafael Espindola2016-05-111-2/+1
| | | | llvm-svn: 269184
* Delete duplicated verifier test.Rafael Espindola2016-05-111-5/+0
| | | | | | Also add unittest to show we still detect the errors. llvm-svn: 269182
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-091-3/+7
| | | | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
* Revert "Allow the LTO code generator to strip invalid debug info from the ↵Adrian Prantl2016-05-091-7/+3
| | | | | | | | input." This reverts commit 268936 while investigating buildbot breakage. llvm-svn: 268940
* Revert "Separate the Verifier into an analysis and a transformation pass and"Adrian Prantl2016-05-091-29/+5
| | | | | | This reverts commit 268937 while investigating build bot breakage. llvm-svn: 268939
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-5/+29
| | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 llvm-svn: 268937
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-091-3/+7
| | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 llvm-svn: 268936
* Refactor the Verifier so it can diagnose IR validation errors and debugAdrian Prantl2016-05-061-159/+195
| | | | | | | | | | | | | | | | | | | | | | | info metadata errors separately. (NFC) This patch refactors the Verifier so it can diagnose IR validation errors and debug info metadata errors separately. The motivation behind this change is that broken (or outdated) debug info can be "recovered" from by stripping the debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19986 rdar://problem/25818489 llvm-svn: 268778
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-241-0/+9
| | | | | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 This reaplies r267320 without changes after fixing an issue in the OpenMP IR generator in clang. llvm-svn: 267370
* Revert "Verifier: Verify that each inlinable callsite of a ↵Adrian Prantl2016-04-241-9/+0
| | | | | | | | debug-info-bearing function" This reverts commit r267320 while investigating an OpenMP buildbot failure. llvm-svn: 267322
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-241-0/+9
| | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 llvm-svn: 267320
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-144/+28
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* Verifier: Add ModuleSlotTracker to printAsOperand callDuncan P. N. Exon Smith2016-04-201-1/+1
| | | | | | I missed this site in r266889. llvm-svn: 266900
* Verifier: Prefer early continue over if-nesting, NFCDuncan P. N. Exon Smith2016-04-201-8/+9
| | | | llvm-svn: 266897
* IR: Use a single ModuleSlotTracker in the VerifierDuncan P. N. Exon Smith2016-04-201-6/+17
| | | | | | | | | | | | Speed up Verifier output by sharing a single ModuleSlotTracker for the duration. There should be no functionality change here except for much faster output when there's more than one statement. Now the Verifier won't be traversing the full Metadata graph every time it prints an error. The TypePrinter is still not shared, but that would take some extra plumbing. llvm-svn: 266889
* IR: Don't use raw_null_ostream in VerifierDuncan P. N. Exon Smith2016-04-201-27/+32
| | | | | | | | While using a raw_null_ostream meant that the Verifier didn't have to think about whether to print, it's actually quite expensive to print out IR. Only print if the output is going somewhere. llvm-svn: 266884
* IR: Use default member initialization in Verifier, NFCDuncan P. N. Exon Smith2016-04-201-5/+4
| | | | llvm-svn: 266883
* IR: Use getRawScope() when verifyingDuncan P. N. Exon Smith2016-04-171-2/+2
| | | | | | | | | | | Fix a couple of places in the Verifier that call `getScope()` instead of `getRawScope()`. Both DIDerivedType::getScope and DICompositeType::getScope return a DITypeRef right now (which wraps a Metadata*) so I don't think there's currently an observable bug. I found this because a future commit that will change them to cast to DIScope*. llvm-svn: 266552
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-11/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Revert "[IR/Verifier] Each DISubprogram with isDefinition: true must belong ↵Davide Italiano2016-04-131-16/+0
| | | | | | | | | to a CU." This reverts commit r266102. The O(N^2) verifier check causes timeouts in LTO test suite. llvm-svn: 266221
* [IR/Verifier] Each DISubprogram with isDefinition: true must belong to a CU.Davide Italiano2016-04-121-0/+16
| | | | | | | | | | | Add a check to catch violations. ~60 tests were broken and prevented this change to be committed. Adrian and I (thanks Adrian!) went through them in the last week or so updating. The check can be done more efficiently but I'd still like to get this in ASAP to avoid more broken tests to be checked in (if any). PR: 27101 llvm-svn: 266102
* Introduce an GCRelocateInst class [NFC]Philip Reames2016-04-121-2/+2
| | | | | | Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor simplifications and code sharing. llvm-svn: 266098
OpenPOWER on IntegriCloud