summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLVM-C] Fix broken build botsRobert Widmann2018-09-281-25/+25
| | | | | | | | | | | | Summary: Fix broken bots caused by the merge of D51522. Reviewers: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52657 llvm-svn: 343334
* [LLVM-C] Add more debug information accessors to GlobalObject and InstructionRobert Widmann2018-09-281-0/+75
| | | | | | | | | | | | | | Summary: Adds missing debug information accessors to GlobalObject. This puts the finishing touches on cloning debug info in the echo tests. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: aprantl, JDevlieghere, llvm-commits, harlanhaskins Differential Revision: https://reviews.llvm.org/D51522 llvm-svn: 343330
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-274-6/+6
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [PassTiming] cleaning up legacy PassTimingInfo interface. NFCI.Fedor Sergeev2018-09-261-51/+60
| | | | | | | | | | | | | | | | | | | | During D51276 discussion it was decided that legacy PassTimingInfo interface can not be reused for new pass manager's implementation of -time-passes. This is a cleanup in preparation for D51276 to make legacy interface as concise as possible, moving the PassTimingInfo from the header into the anonymous legacy namespace in .cpp. It is rather close to a revert of rL340872 in a sense that it hides the interface and gets rid of templates. However as compared to a complete revert it resides in a different translation unit and has an additional pass-instance counting funcitonality (PassIDCountMap). Reviewers: philip.pfaffe Differential Revision: https://reviews.llvm.org/D52356 llvm-svn: 343104
* [ThinLTO] Efficiency fix for writing type id records in per-module indexesTeresa Johnson2018-09-251-20/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D49565/r337503, the type id record writing was fixed so that only referenced type ids were emitted into each per-module index for ThinLTO distributed builds. However, this still left an efficiency issue: each per-module index checked all type ids for membership in the referenced set, yielding O(M*N) performance (M indexes and N type ids). Change the TypeIdMap in the summary to be indexed by GUID, to facilitate correlating with type identifier GUIDs referenced in the function summary TypeIdInfo structures. This allowed simplifying other places where a map from type id GUID to type id map entry was previously being used to aid this correlation. Also fix AsmWriter code to handle the rare case of type id GUID collision. For a large internal application, this reduced the thin link time by almost 15%. Reviewers: pcc, vitalybuka Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51330 llvm-svn: 343021
* [New PM][PassInstrumentation] IR printing support for New Pass ManagerFedor Sergeev2018-09-241-12/+16
| | | | | | | | | | | | | | | | Implementing -print-before-all/-print-after-all/-filter-print-func support through PassInstrumentation callbacks. - PrintIR routines implement printing callbacks. - StandardInstrumentations class provides a central place to manage all the "standard" in-tree pass instrumentations. Currently it registers PrintIR callbacks. Reviewers: chandlerc, paquette, philip.pfaffe Differential Revision: https://reviews.llvm.org/D50923 llvm-svn: 342896
* Pass code-model through Module IR to LTO which will use it.Caroline Tice2018-09-211-0/+19
| | | | | | | | | | | Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is not propagated properly to LTO. This patch, along with one for the front end, fixes that. Differential Revision: https://reviews.llvm.org/D52322 llvm-svn: 342760
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-202-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
* [IR] add shuffle query for vector concatenationSanjay Patel2018-09-201-0/+17
| | | | | | This can be used for combining and in the vectorizers/cost models. llvm-svn: 342653
* [IR] Add a boolean field in DILocation to know if a line must covered or notCalixte Denizet2018-09-204-15/+36
| | | | | | | | | | | | | | | | | | | | | Summary: Some lines have a hit counter where they should not have one. For example, in C++, some cleanup is adding at the end of a scope represented by a '}'. So such a line has a hit counter where a user expects to not have one. The goal of the patch is to add this information in DILocation which is used to get the covered lines in GCOVProfiling.cpp. A following patch in clang will add this information when generating IR (https://reviews.llvm.org/D49916). Reviewers: marco-c, davidxl, vsk, javed.absar, rnk Reviewed By: rnk Subscribers: eraman, xur, danielcdh, aprantl, rnk, dblaikie, #debug-info, vsk, llvm-commits, sylvestre.ledru Tags: #debug-info Differential Revision: https://reviews.llvm.org/D49915 llvm-svn: 342631
* Temporarily Revert "[New PM] Introducing PassInstrumentation framework"Eric Christopher2018-09-202-23/+0
| | | | | | | | as it was causing failures in the asan buildbot. This reverts commit r342597. llvm-svn: 342616
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342597
* Revert rL342544: [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-23/+0
| | | | | | A bunch of bots fail to compile unittests. Reverting. llvm-svn: 342552
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342544
* [LLVM-C][OCaml] Add C and OCaml APIs for llvm::StructType::isLiteralwhitequark2018-09-181-0/+4
| | | | | | | | | | | | | | | | | Summary: This patch adds LLVMIsLiteralStruct to the C API to expose StructType::isLiteral. This is then used to implement the analogous addition to the OCaml API. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52209 llvm-svn: 342435
* [LLVM-C] Add support for ConstantExpr in LLVMGetNumIndices and LLVMGetIndiceswhitequark2018-09-181-0/+4
| | | | | | | | | | | | | | | | Summary: ConstantExpr supports getIndices, but prior to this patch LLVMGetNumIndices and LLVMGetIndices would error on them. Reviewers: whitequark Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52206 llvm-svn: 342434
* fix 80-column violation with clang-formatAdrian Prantl2018-09-121-7/+4
| | | | llvm-svn: 342094
* [AArch64] Add parsing of aarch64_vector_pcs attribute.Sander de Smalen2018-09-121-0/+1
| | | | | | | | | | | | | | | | | | | This patch adds parsing support for the 'aarch64_vector_pcs' calling convention attribute to calls and function declarations. More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Reviewers: t.p.northover, rnk, rengolin, javed.absar, thegameg, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D51477 llvm-svn: 342030
* Add some context to fatal verifier errorsXin Tong2018-09-111-2/+3
| | | | | | | | | | | | | | | | Summary: Add function name when verification fails as an initial breadcrumb for debugging. Patch by David Callahan. Reviewers: mehdi_amini, modocache Reviewed By: modocache Subscribers: llvm-commits, modocache Differential Revision: https://reviews.llvm.org/D51386 llvm-svn: 341974
* Remove addBlockByrefAddress(), it is dead code as far as clang is concerned.Adrian Prantl2018-09-081-0/+8
| | | | | | | | | | | | This patch removes addBlockByrefAddress(), it is dead code as far as clang is concerned: Every byref block capture is emitted with a complex expression that is equivalent to what this function does. rdar://problem/31629055 Differential Revision: https://reviews.llvm.org/D51763 llvm-svn: 341737
* [X86] Modify the the rdtscp intrinsic to return values instead of taking a ↵Craig Topper2018-09-071-0/+37
| | | | | | | | | | pointer argument Similar to what was recently done for addcarry/subborrow and has been done for rdrand/rdseed for a while. It's better to use two results and an explicit store in IR when the store isn't part of the semantics of the instruction. This allows store->load forwarding to happen in the middle end. Or the store to be removed if its never loaded. Differential Revision: https://reviews.llvm.org/D51803 llvm-svn: 341698
* [X86] Change the addcarry and subborrow intrinsics to return 2 results and ↵Craig Topper2018-09-071-0/+58
| | | | | | | | | | remove the pointer argument. We should represent the store directly in IR instead. This gives the middle end a chance to remove it if it can see a load from the same address. Differential Revision: https://reviews.llvm.org/D51769 llvm-svn: 341677
* Output per-function size-info remarksJessica Paquette2018-09-061-12/+111
| | | | | | | | | | | This patch adds per-function size information remarks. Previously, passing -Rpass-analysis=size-info would only give you per-module changes. By adding the ability to do this per-function, it's easier to see which functions contributed the most to size changes. https://reviews.llvm.org/D51467 llvm-svn: 341588
* [SLC] Add an alignment to CreateGlobalStringDavid Green2018-09-061-0/+1
| | | | | | | | | | | | | | | | Previously the alignment on the newly created global strings was not set, meaning that DataLayout::getPreferredAlignment was free to overalign it to 16 bytes. This caused unnecessary code bloat with the padding between variables. The main example of this happening was the printf->puts optimisation in SimplifyLibCalls, but as the change here is made in IRBuilderBase::CreateGlobalString, other globals using this will now be aligned too. Differential Revision: https://reviews.llvm.org/D51410 llvm-svn: 341527
* [NFC] Improve clarity in emitInstrCountChangedRemarkJessica Paquette2018-09-041-1/+4
| | | | | | | | | Add a "CouldOnlyImpactOneFunction" bool that's true when we pass in a function. Just cleaning up a little bit, since I'm going to add in the per-function remarks soon from D51467. llvm-svn: 341407
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-042-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [PassTiming] reporting time-passes separately for multiple pass instances of ↵Fedor Sergeev2018-09-041-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
* Fix typo in size remarks for module passesJessica Paquette2018-08-311-1/+1
| | | | | | | | | | | | | | | ModuleCount = InstrCount was incorrect. It should have been InstrCount = ModuleCount. This was making it emit an extra, incorrect remark for Print Module IR. The test didn't catch this, because it didn't ensure that the only remark output was from the desired pass. So, it was possible to have an extra remark come through and not fail. Updated the test so that we ensure that the last remark that's output comes from the desired pass. This is done by ensuring that whatever is being read after the last remark is YAML output rather than some incorrect garbage. llvm-svn: 341267
* [NFC] Optionally pass a function to emitInstrCountChangedRemarkJessica Paquette2018-08-311-14/+18
| | | | | | | | | In basic block, loop, and function passes, we already have a function that we can use to emit optimization remarks. We can use that instead of searching the module for the first suitable function (that is, one that contains at least one basic block.) llvm-svn: 341253
* [NFC] Check if P is a pass manager on entry to emitInstrCountChangedRemarkJessica Paquette2018-08-311-7/+7
| | | | | | | There's no point in finding a function to use for remark output when we're not going to emit anything. llvm-svn: 341252
* [NFC] Pass the instruction delta to emitInstrCountChangedRemarkJessica Paquette2018-08-311-19/+7
| | | | | | | | | | | | | | | Instead of counting the size of the entire module every time we run a pass, pass along a delta instead and use that to emit the remark. This means we only have to use (on average) smaller IR units to calculate instruction counts. E.g, in a BB pass, we only need to look at the delta of the BB instead of the delta of the entire module. 6/6 (This improved compile time for size remarks on sqlite3 + O2 significantly) llvm-svn: 341250
* [NFC] Pre-calculate module IR counts in size remarks.Jessica Paquette2018-08-311-5/+18
| | | | | | | | | | | | | | | Same as the previous NFC commits in the same vein. This one introduces a TODO. I'm going to change emitInstrCountChangedRemark so that it takes in a delta. Since the delta isn't necessary yet, it's not there. For now, this means that we're calculating the size of the module twice. Just done separately to keep the patches small. 4/6 llvm-svn: 341248
* [NFC] Pre-calculate basic block IR counts in size remarks.Jessica Paquette2018-08-311-6/+21
| | | | | | | | | | | Size remarks are slow due to lots of recalculation of the module. This is similar to the previous commit. Cache the size of the module and update counts in basic block passes based off a less-expensive delta. 2/6 llvm-svn: 341246
* [NFC] Pre-calculate function IR counts in size remarks.Jessica Paquette2018-08-311-5/+20
| | | | | | | | | | | | Size remarks are slow due to lots of recalculation of the module. Pre-calculate the module size and initial function size for a remark. Use deltas calculated using the less-expensive function IR count to update the module counts for Function passes. 1/6 llvm-svn: 341245
* [LLVM-C] Add Bindings For Named MetadataRobert Widmann2018-08-301-0/+48
| | | | | | | | | | | | | | Summary: Add a new type for named metadata nodes. Use this to implement iterators and accessors for NamedMDNodes and extend the echo test to use them to copy module-level debug information. Reviewers: whitequark, deadalnix, aprantl, dexonsmith Reviewed By: whitequark Subscribers: Wallbraker, JDevlieghere, llvm-commits, harlanhaskins Differential Revision: https://reviews.llvm.org/D47179 llvm-svn: 341085
* [IR] fix declaration of shuffle maskSanjay Patel2018-08-301-1/+1
| | | | | | An address sanitizer bot flagged this as a potential bug. llvm-svn: 341084
* [IR] add shuffle queries for identity extend/extract Sanjay Patel2018-08-301-9/+48
| | | | | | | | | | | | | | | This was one of the potential follow-ups suggested in D48236, and these will be used to make matching the patterns in PR38691 cleaner: https://bugs.llvm.org/show_bug.cgi?id=38691 About the vocabulary: in the DAG, these would be concat_vector with an undef operand or extract_subvector. Alternate names are discussed in the review, but I think these are familiar/good enough to proceed. Once we have uses of them in code, we might adjust if there are better options. https://reviews.llvm.org/D51392 llvm-svn: 341075
* [NFC] Make getPreferredAlignment honor section markings.Eli Friedman2018-08-291-1/+15
| | | | | | | | | | | | | This should more accurately reflect what the AsmPrinter will actually do. This is NFC, as far as I can tell; all the places that might be affected already have an extra check to avoid using the result of getPreferredAlignment in this situation. Differential Revision: https://reviews.llvm.org/D51377 llvm-svn: 340999
* [NFC][PassTiming] factor out generic PassTimingInfoFedor Sergeev2018-08-283-96/+134
| | | | | | | | Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-1/+1
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Sink `isExceptional` predicate to `Instruction`, rename it toChandler Carruth2018-08-261-1/+1
| | | | | | | | | | | `isExceptionalTermiantor` and implement it for opcodes as well following the common pattern in `Instruction`. Part of removing `TerminatorInst` from the `Instruction` type hierarchy to make it easier to share logic and interfaces between instructions that are both terminators and not terminators. llvm-svn: 340699
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-263-41/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [C-API][DIBuilder] Use NameLen in LLVMDIBuilderCreateParameterVariableRobert Widmann2018-08-251-1/+1
| | | | | | | | | | | | | | Summary: NameLen wasn't being used and caused the parameters in gdb to very long, in my case, crashes in others. Please also perform the correct magical incarnations to have this be applied to the LLVM 7 branch. Reviewers: whitequark, CodaFi Reviewed By: CodaFi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51141 llvm-svn: 340691
* Prevent DILocation::getMergedLocation() from creating invalid metadata.Adrian Prantl2018-08-241-0/+5
| | | | | | | | | | | | | | | | The function's new implementation from r340583 had a bug in it that could cause an invalid scope to be generated when merging two DILocations with no common ancestor scope. This patch detects this situation and picks the scope of the first location. This is not perfect, because the scope is misleading, but on the other hand, this will be a line 0 location. rdar://problem/43687474 Differential Revision: https://reviews.llvm.org/D51238 llvm-svn: 340672
* Verifier: verify that a DILocation's scope is a DILocalScope.Adrian Prantl2018-08-241-0/+4
| | | | | | | | This fixes an assertion failure(!) in the Verifier. rdar://problem/43687474 llvm-svn: 340653
* DebugInfo: Improve debug location mergingDavid Blaikie2018-08-232-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a set of related bugs: * Considering two locations as equivalent when their lines are the same but their scopes are different causes erroneous debug info that attributes a commoned call to be attributed to one of the two calls it was commoned from. * The previous code to compute a new location's scope was inaccurate and would use the inlinedAt that was the /parent/ of the inlinedAt that is the nearest common one, and also used that parent scope instead of the nearest common scope. * Not generating new locations generally seemed like a lower quality choice There was some risk that generating more new locations could hurt object size by making more fine grained line table entries, but it looks like that was offset by the decrease in line table (& address & ranges) size caused by more accurately computing the scope - which likely lead to fewer range entries (more contiguous ranges) & reduced size that way. All up with these changes I saw minor reductions (-1.21%, -1.77%) in .rela.debug_ranges and .rela.debug_addr (in a fission, compressed debug info build) as well as other minor size changes (generally reductinos) across the board (-1.32% debug_info.dwo, -1.28% debug_loc.dwo). Measured in an optimized (-O2) build of the clang binary. If you are investigating a size regression in an optimized debug builds, this is certainly a patch to look into - and I'd be happy to look into any major regressions found & see what we can do to address them. llvm-svn: 340583
* [DEBUGINFO] Fix misprint in the name of DebugDirectivesOnly, NFC.Alexey Bataev2018-08-231-1/+1
| | | | llvm-svn: 340553
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-235-8/+59
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* [IR Verifier] Do not allow bitcast of pointer to vector of pointers and vice ↵Serguei Katkov2018-08-211-6/+8
| | | | | | | | | | | | | | | | | | versa. LangRef for BitCast requires that "The bit sizes of value and the destination type, ty2, must be identical". Currently verifier allows BitCast of pointer to vector of pointers so that the sizes are different. This change fixes that. Reviewers: arsenm Reviewed By: arsenm Subscribers: llvm-commits, wdng Differential Revision: https://reviews.llvm.org/D50886 llvm-svn: 340249
* [LegacyPassManager] Remove analysis P from AnUsageMap before deleting it in ↵Craig Topper2018-08-201-0/+2
| | | | | | | | | | | | schedulePass. If we deem the analysis pass useless and delete it, we need to make sure we remove it from AnUsageMap. Otherwise we might allocate another pass in the freed memory. This will cause us to reuse the AnalysisUsage from the original pass instead of the new one. Fixes PR38511 Differential Revision: https://reviews.llvm.org/D50573 llvm-svn: 340210
OpenPOWER on IntegriCloud