summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Recommit r350554 "[X86] Remove AVX512VBMI2 concat and shift intrinsics. ↵Craig Topper2019-01-071-42/+50
| | | | | | | | Replace with target independent funnel shift intrinsics." The MSVC limit we hit on AutoUpgrade.cpp has been worked around for now. llvm-svn: 350567
* [X86][AutoUpgrade] Make some tweaks to reduce the number of nested if/else ↵Craig Topper2019-01-071-96/+79
| | | | | | | | | | | | in the intrinsic upgrade code to avoid an MSVC compiler limit. MSVC has a nesting limit of around 110-130. An if/else if/else if counts against this next level. The autoupgrade code consists a long chain of these checking matches against strings. This commit moves some code to a helper function to move out a large if/else chain that was inside of one of the blocks into a separate function. There are more of these we could move or we could change some to lookup tables. I've also merged together a few similar blocks in the outer chain. This should buy us some margin for a little bit. llvm-svn: 350564
* Revert r350554 "[X86] Remove AVX512VBMI2 concat and shift intrinsics. ↵Craig Topper2019-01-071-50/+42
| | | | | | | | Replace with target independent funnel shift intrinsics." The AutoUpgrade.cpp if/else cascade hit an MSVC limit again. llvm-svn: 350562
* [X86] Remove AVX512VBMI2 concat and shift intrinsics. Replace with target ↵Craig Topper2019-01-071-42/+50
| | | | | | | | independent funnel shift intrinsics. Differential Revision: https://reviews.llvm.org/D56377 llvm-svn: 350554
* [CallSite removal] Move the rest of IR implementation code away fromChandler Carruth2019-01-074-51/+44
| | | | | | | | | | | | | | `CallSite`. With this change, the remaining `CallSite` usages are just for implementing the wrapper type itself. This does update the C API but leaves the names of that API alone and only updates their implementation. Differential Revision: https://reviews.llvm.org/D56184 llvm-svn: 350509
* [CallSite removal] Port `IndirectCallSiteVisitor` to use `CallBase` andChandler Carruth2019-01-071-0/+10
| | | | | | | | | | | update client code. Also rename it to use the more generic term `call` instead of something that could be confused with a praticular type. Differential Revision: https://reviews.llvm.org/D56183 llvm-svn: 350508
* [CallSite removal] Move the verifier to use `CallBase` instead of theChandler Carruth2019-01-071-284/+284
| | | | | | | | | | | `CallSite` wrapper. Mostly mechanical, but I've tried to tidy up code where it made sense to do so. Differential Revision: https://reviews.llvm.org/D56143 llvm-svn: 350507
* Revert patches 348835 and 348571 because they'reRanjeet Singh2019-01-041-5/+4
| | | | | | causing code size performance regressions. llvm-svn: 350402
* [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)Hal Finkel2019-01-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Motivated by the discussion in D38499, this patch updates BasicAA to support arbitrary pointer sizes by switching most remaining non-APInt calculations to use APInt. The size of these APInts is set to the maximum pointer size (maximum over all address spaces described by the data layout string). Most of this translation is straightforward, but this patch contains a fix for a bug that revealed itself during this translation process. In order for test/Analysis/BasicAA/gep-and-alias.ll to pass, which is run with 32-bit pointers, the intermediate calculations must be performed using 64-bit integers. This is because, as noted in the patch, when GetLinearExpression decomposes an expression into C1*V+C2, and we then multiply this by Scale, and distribute, to get (C1*Scale)*V + C2*Scale, it can be the case that, even through C1*V+C2 does not overflow for relevant values of V, (C2*Scale) can overflow. If this happens, later logic will draw invalid conclusions from the (base) offset value. Thus, when initially applying the APInt conversion, because the maximum pointer size in this test is 32 bits, it started failing. Suspicious, I created a 64-bit version of this test (included here), and that failed (miscompiled) on trunk for a similar reason (the multiplication can overflow). After fixing this overflow bug, the first test case (at least) in Analysis/BasicAA/q.bad.ll started failing. This is also a 32-bit test, and was relying on having 64-bit intermediate values to have BasicAA return an accurate result. In order to fix this problem, and because I believe that it is not uncommon to use i64 indexing expressions in 32-bit code (especially portable code using int64_t), it seems reasonable to always use at least 64-bit integers. In this way, we won't regress our analysis capabilities (and there's a command-line option added, so experimenting with this should be easy). As pointed out by Eli during the review, there are other potential overflow conditions that this patch does not address. Fixing those is left to follow-up work. Patch by me with contributions from Michael Ferguson (mferguson@cray.com). Differential Revision: https://reviews.llvm.org/D38662 llvm-svn: 350220
* Extend Module::getOrInsertGlobal to control the construction of thePhilip Pfaffe2019-01-021-8/+14
| | | | | | | | | | | | | | | | | | GlobalVariable Summary: Extend Module::getOrInsertGlobal to accept a callback for creating a new GlobalVariable if necessary instead of calling the GV constructor directly using default arguments. Additionally overload getOrInsertGlobal for the previous default behavior. Reviewers: chandlerc Subscribers: hiraditya, llvm-commits, bollu Differential Revision: https://reviews.llvm.org/D56130 llvm-svn: 350219
* [LLVM-C] bool -> LLVMBoolRobert Widmann2019-01-011-2/+2
| | | | llvm-svn: 350197
* [LLVM-C] Add Accessors for Discarding Value Names in the IRRobert Widmann2019-01-011-0/+8
| | | | | | | | | | | | | | Summary: Add accessors so the performance improvement from this setting is accessible to third parties. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56179 llvm-svn: 350196
* Add vtable anchor to classes.Richard Trieu2018-12-291-0/+8
| | | | llvm-svn: 350142
* [CallSite removal] Add and flesh out APIs on the new `CallBase` base class ↵Chandler Carruth2018-12-271-0/+21
| | | | | | | | | | | | | | | | | | | that previously were only available on the `CallSite` wrapper. Summary: This will make migrating code easier and generally seems like a good collection of API improvements. Some of these APIs seem like more consistent / better naming of existing ones. I've retained the old names for migration simplicit and am just adding the new ones in this commit. I'll try to garbage collect these once CallSite is gone. Subscribers: sanjoy, mcrosier, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D55638 llvm-svn: 350109
* [llvm] API for encoding/decoding DWARF discriminators.Mircea Trofin2018-12-211-0/+43
| | | | | | | | | | | | | | | | | | | Summary: Added a pair of APIs for encoding/decoding the 3 components of a DWARF discriminator described in http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html: the base discriminator, the duplication factor (useful in profile-guided optimization) and the copy index (used to identify copies of code in cases like loop unrolling) The encoding packs 3 unsigned values in 32 bits. This CL addresses 2 issues: - communicates overflow back to the user - supports encoding all 3 components together. Current APIs assume a sequencing of events. For example, creating a new discriminator based on an existing one by changing the base discriminator was not supported. Reviewers: davidxl, danielcdh, wmi, dblaikie Reviewed By: dblaikie Subscribers: zzheng, dmgreen, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D55681 llvm-svn: 349973
* [IR] Add Instruction::isLifetimeStartOrEnd, NFCVedant Kumar2018-12-212-4/+10
| | | | | | | | | | | Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an llvm.lifetime.start or an llvm.lifetime.end intrinsic. This was suggested as a cleanup in D55967. Differential Revision: https://reviews.llvm.org/D56019 llvm-svn: 349964
* [X86][SSE] Auto upgrade PADDS/PSUBS intrinsics to SADD_SAT/SSUB_SAT generic ↵Simon Pilgrim2018-12-211-35/+23
| | | | | | | | | | | | intrinsics (llvm) This auto upgrades the signed SSE saturated math intrinsics to SADD_SAT/SSUB_SAT generic intrinsics. Clang counterpart: https://reviews.llvm.org/D55890 Differential Revision: https://reviews.llvm.org/D55894 llvm-svn: 349892
* [X86] Auto upgrade XOP/AVX512 rotation intrinsics to generic funnel shift ↵Simon Pilgrim2018-12-201-64/+41
| | | | | | | | | | | | intrinsics (llvm) This emits FSHL/FSHR generic intrinsics for the XOP VPROT and AVX512 VPROL/VPROR rotation intrinsics. Clang counterpart: https://reviews.llvm.org/D55937 Differential Revision: https://reviews.llvm.org/D55938 llvm-svn: 349795
* Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.Michael Kruse2018-12-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current llvm.mem.parallel_loop_access metadata has a problem in that it uses LoopIDs. LoopID unfortunately is not loop identifier. It is neither unique (there's even a regression test assigning the some LoopID to multiple loops; can otherwise happen if passes such as LoopVersioning make copies of entire loops) nor persistent (every time a property is removed/added from a LoopID's MDNode, it will also receive a new LoopID; this happens e.g. when calling Loop::setLoopAlreadyUnrolled()). Since most loop transformation passes change the loop attributes (even if it just to mark that a loop should not be processed again as llvm.loop.isvectorized does, for the versioned and unversioned loop), the parallel access information is lost for any subsequent pass. This patch unlinks LoopIDs and parallel accesses. llvm.mem.parallel_loop_access metadata on instruction is replaced by llvm.access.group metadata. llvm.access.group points to a distinct MDNode with no operands (avoiding the problem to ever need to add/remove operands), called "access group". Alternatively, it can point to a list of access groups. The LoopID then has an attribute llvm.loop.parallel_accesses with all the access groups that are parallel (no dependencies carries by this loop). This intentionally avoid any kind of "ID". Loops that are clones/have their attributes modifies retain the llvm.loop.parallel_accesses attribute. Access instructions that a cloned point to the same access group. It is not necessary for each access to have it's own "ID" MDNode, but those memory access instructions with the same behavior can be grouped together. The behavior of llvm.mem.parallel_loop_access is not changed by this patch, but should be considered deprecated. Differential Revision: https://reviews.llvm.org/D52116 llvm-svn: 349725
* llvm-dwarfdump: Improve/fix pretty printing of array dimensionsDavid Blaikie2018-12-191-2/+3
| | | | | | | | | | | | | | This is to address post-commit feedback from Paul Robinson on r348954. The original commit misinterprets count and upper bound as the same thing (I thought I saw GCC producing an upper bound the same as Clang's count, but GCC correctly produces an upper bound that's one less than the count (in C, that is, where arrays are zero indexed)). I want to preserve the C-like output for the common case, so in the absence of a lower bound the count (or one greater than the upper bound) is rendered between []. In the trickier cases, where a lower bound is specified, a half-open range is used (eg: lower bound 1, count 2 would be "[1, 3)" and an unknown parts use a '?' (eg: "[1, ?)" or "[?, 7)" or "[?, ? + 3)"). Reviewers: aprantl, probinson, JDevlieghere Differential Revision: https://reviews.llvm.org/D55721 llvm-svn: 349670
* [X86][SSE] Auto upgrade PADDUS/PSUBUS intrinsics to UADD_SAT/USUB_SAT ↵Simon Pilgrim2018-12-191-17/+4
| | | | | | | | | | | | | | generic intrinsics (llvm) Now that we use the generic ISD opcodes, we can use the generic intrinsics directly as well. This fixes the poor fast-isel codegen by not expanding to an easily broken IR code sequence. I'm intending to deal with the signed saturation equivalents as well. Clang counterpart: https://reviews.llvm.org/D55879 Differential Revision: https://reviews.llvm.org/D55855 llvm-svn: 349630
* Implement -frecord-command-line (-frecord-gcc-switches)Scott Linder2018-12-141-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | Implement options in clang to enable recording the driver command-line in an ELF section. Implement a new special named metadata, llvm.commandline, to support frontends embedding their command-line options in IR/ASM/ELF. This differs from the GCC implementation in some key ways: * In GCC there is only one command-line possible per compilation-unit, in LLVM it mirrors llvm.ident and multiple are allowed. * In GCC individual options are separated by NULL bytes, in LLVM entire command-lines are separated by NULL bytes. The advantage of the GCC approach is to clearly delineate options in the face of embedded spaces. The advantage of the LLVM approach is to support merging multiple command-lines unambiguously, while handling embedded spaces with escaping. Differential Revision: https://reviews.llvm.org/D54487 Clang Differential Revision: https://reviews.llvm.org/D54489 llvm-svn: 349155
* [macho] save the SDK version stored in module metadata into the version min andAlex Lorenz2018-12-141-0/+40
| | | | | | | | | | | | | | | | | | | | | build version load commands in the object file This commit introduces a new metadata node called "SDK Version". It will be set by the frontend to mark the platform SDK (macOS/iOS/etc) version which was used during that particular compilation. This node is used when machine code is emitted, by either saving the SDK version into the appropriate macho load command (version min/build version), or by emitting the assembly for these load commands with the SDK version specified as well. The assembly for both load commands is extended by allowing it to contain the sdk_version X, Y [, Z] trailing directive to represent the SDK version respectively. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55612 llvm-svn: 349119
* [mir] Serialize DILocation inline when not possible to use a metadata referenceDaniel Sanders2018-12-131-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes MIR-level passes create DILocations that were not present in the LLVM-IR. For example, it may merge two DILocations together to produce a DILocation that points to line 0. Previously, the address of these DILocations were printed which prevented the MIR from being read back into LLVM. With this patch, DILocations will use metadata references where possible and fall back on serializing them inline like so: MOV32mr %stack.0.x.addr, 1, _, 0, _, %0, debug-location !DILocation(line: 1, scope: !15) Reviewers: aprantl, vsk, arphaman Reviewed By: aprantl Subscribers: probinson, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D55243 llvm-svn: 349035
* [ConstantFold] Use getMinSignedBits for APInt in isIndexInRangeOfArrayType.Florian Hahn2018-12-121-1/+1
| | | | | | | | | | | | | | | | | Indices for getelementptr can be signed so we should use getMinSignedBits instead of getActiveBits here. The function later calls getSExtValue to get the int64_t value, which also checks getMinSignedBits. This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11647. Reviewers: mssimpso, efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D55536 llvm-svn: 348957
* [Intrinsic] Signed Fixed Point Multiplication IntrinsicLeonard Chan2018-12-121-0/+18
| | | | | | | | | | | | Add an intrinsic that takes 2 signed integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D54719 llvm-svn: 348912
* [ConstantInt] Check active bits before calling getZExtValue.Florian Hahn2018-12-121-1/+5
| | | | | | | | | | | | | | | | | | Without this check, we hit an assertion in getZExtValue, if the constant value does not fit into an uint64_t. As getZExtValue returns an uint64_t, should we update getAggregateElement to take an uin64_t as well? This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6109. Reviewers: efriedma, craig.topper, spatel Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D55547 llvm-svn: 348906
* [NewPM] fixing asserts on deleted loop in -print-after-allFedor Sergeev2018-12-111-6/+8
| | | | | | | | | | | IR-printing AfterPass instrumentation might be called on a loop that has just been invalidated. We should skip printing it to avoid spurious asserts. Reviewed By: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D54740 llvm-svn: 348887
* APFloat: allow 64-bit of payloadJF Bastien2018-12-101-2/+24
| | | | | | | | | | | | | | | | | | | | Summary: The APFloat and Constant APIs taking an APInt allow arbitrary payloads, and that's great. There's a convenience API which takes an unsigned, and that's silly because it then directly creates a 64-bit APInt. Just change it to 64-bits directly. At the same time, add ConstantFP NaN getters which match the APFloat ones (with getQNaN / getSNaN and APInt parameters). Improve the APFloat testing to set more payload bits. Reviewers: scanon, rjmccall Subscribers: jkorous, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D55460 llvm-svn: 348791
* [X86] Merge addcarryx/addcarry intrinsic into a single addcarry intrinsic.Craig Topper2018-12-101-59/+40
| | | | | | | | Both intrinsics do the exact same thing so we really only need one. Earlier in the 8.0 cycle we changed the signature of this intrinsic without renaming it. But it looks difficult to get the autoupgrade code to allow me to merge the intrinsics and change the signature at the same time. So I've renamed the intrinsic slightly for the new merged intrinsic. I'm skipping autoupgrading from the previous new to 8.0 signature. I've also renamed the subborrow for consistency. llvm-svn: 348737
* [X86] Add some comments about when some X86 intrinsic autoupgrade code was ↵Craig Topper2018-12-091-7/+7
| | | | | | | | added. Someday we'd like to remove old autoupgrade code so it helps to annotate how long its been there so we don't have to go digging through commit history. llvm-svn: 348728
* [IR] Don't assume all functions are 4 byte alignedRanjeet Singh2018-12-071-4/+5
| | | | | | | | | | | | | | | | | In some cases different alignments for function might be used to save space e.g. thumb mode with -Oz will try to use 2 byte function alignment. Similar patch that fixed this in other areas exists here https://reviews.llvm.org/D46110 This was approved previously https://reviews.llvm.org/D55115 (r348215) but when committed it caused failures on the sanitizer buildbots when building llvm with clang (containing this patch). This is now fixed because I've added a check to see if getting the parent module returns null if it does then set the alignment to 0. Differential Revision: https://reviews.llvm.org/D55115 llvm-svn: 348571
* Reapply "Adapt gcov to changes in CFE."Adrian Prantl2018-12-061-11/+31
| | | | | | | | | | | | | | | | | | | | This reverts commit r348203 and reapplies D55085 with an additional GCOV bugfix to make the change NFC for relative file paths in .gcno files. Thanks to Ilya Biryukov for additional testing! Original commit message: Update Diagnostic handling for changes in CFE. The clang frontend no longer emits the current working directory for DIFiles containing an absolute path in the filename: and will move the common prefix between current working directory and the file into the directory: component. https://reviews.llvm.org/D55085 llvm-svn: 348512
* Revert "Adapt gcov to changes in CFE."Ilya Biryukov2018-12-041-31/+11
| | | | | | | | | | | | This reverts commit r348203. Reason: this produces absolute paths in .gcno files, breaking us internally as we rely on them being consistent with the filenames passed in the command line. Also reverts r348157 and r348155 to account for revert of r348154 in clang repository. llvm-svn: 348279
* Reverting r348215Ranjeet Singh2018-12-041-3/+4
| | | | | | Causing failures on ubsan buildbot boxes. llvm-svn: 348230
* [IR] Don't assume all functions are 4 byte alignedRanjeet Singh2018-12-041-4/+3
| | | | | | | | | | | In some cases different alignments for function might be used to save space e.g. thumb mode with -Oz will try to use 2 byte function alignment. Similar patch that fixed this in other areas exists here https://reviews.llvm.org/D46110 Differential Revision: https://reviews.llvm.org/D55115 llvm-svn: 348215
* Fix non-modular build.Adrian Prantl2018-12-031-0/+4
| | | | llvm-svn: 348157
* Update Diagnostic handling for changes in CFE.Adrian Prantl2018-12-031-11/+27
| | | | | | | | | | | The clang frontend no longer emits the current working directory for DIFiles containing an absolute path in the filename: and will move the common prefix between current working directory and the file into the directory: component. https://reviews.llvm.org/D55085 llvm-svn: 348155
* [InstCombine] Support ssub.sat canonicalization for non-splatsNikita Popov2018-12-011-11/+8
| | | | | | | | | | | | Extend ssub.sat(X, C) -> sadd.sat(X, -C) canonicalization to also support non-splat vector constants. This is done by generalizing the implementation of the isNotMinSignedValue() helper to return true for constants that are non-splat, but don't contain any signed min elements. Differential Revision: https://reviews.llvm.org/D55011 llvm-svn: 348072
* [DWARFv5] Verify all-or-nothing constraint on DIFile sourceScott Linder2018-11-301-0/+18
| | | | | | | | | Update IR verifier to check the constraint that DIFile source is present on all files or no files. Differential Revision: https://reviews.llvm.org/D54953 llvm-svn: 348022
* Comment tweak requested in code review. NFCPaul Robinson2018-11-291-1/+2
| | | | | | I forgot to do this before committing D54755. llvm-svn: 347918
* [Inliner] Modify the merging of min-legal-vector-width attribute to better ↵Craig Topper2018-11-291-12/+16
| | | | | | | | | | handle when the caller or callee don't have the attribute. Lack of an attribute means that the function hasn't been checked for what vector width it requires. So if the caller or the callee doesn't have the attribute we should make sure the combined function after inlining does not have the attribute. If the caller already doesn't have the attribute we can just avoid adding it. Otherwise if the callee doesn't have the attribute just remove the caller's attribute. llvm-svn: 347841
* [DebugInfo] IR/Bitcode changes for DISubprogram flags.Paul Robinson2018-11-282-5/+60
| | | | | | | | | Packing the flags into one bitcode word will save effort in adding new flags in the future. Differential Revision: https://reviews.llvm.org/D54755 llvm-svn: 347806
* [ThinLTO] Assembly representation of ReadOnly attributeEugene Leviant2018-11-231-1/+3
| | | | | | Differential revision: https://reviews.llvm.org/D54754 llvm-svn: 347489
* [TI removal] Leverage the fact that TerminatorInst is gone to createChandler Carruth2018-11-222-37/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a normal base class that provides all common "call" functionality. This merges two complex CRTP mixins for the common "call" logic and common operand bundle logic into a single, normal base class of `CallInst` and `InvokeInst`. Going forward, users can typically `dyn_cast<CallBase>` and use the resulting API. No more need for the `CallSite` wrapper. I'm planning to migrate current usage of the wrapper to directly use the base class and then it can be removed, but those are simpler and much more incremental steps. The big change is to introduce this abstraction into the type system. I've tried to do some basic simplifications of the APIs that I couldn't really help but touch as part of this: - I've tried to organize the attribute API and bundle API into groups to make understanding the API of `CallBase` easier. Without this, I wasn't able to navigate the API sanely for all of the ways I needed to modify it. - I've added what seem like more clear and consistent APIs for getting at the called operand. These ended up being especially useful to consolidate the *numerous* duplicated code paths trying to do this. - I've largely reworked the organization and implementation of the APIs for computing the argument operands as they needed to change to work with the new subclass approach. To minimize any cost associated with this abstraction, I've moved the operand layout in memory to store the called operand last. This makes its position relative to the end of the operand array the same, regardless of the subclass. It should make it much cheaper to reference from the `CallBase` abstraction, and this is likely one of the most frequent things to query. We do still pay one abstraction penalty here: we have to branch to determine whether there are 0 or 2 extra operands when computing the end of the argument operand sequence. However, that seems both rare and should optimize well. I've implemented this in a way specifically designed to allow it to optimize fairly well. If this shows up in profiles, we can add overrides of the relevant methods to the subclasses that bypass this penalty. It seems very unlikely that this will be an issue as the code was *already* dealing with an ever present abstraction of whether or not there are operand bundles, so this isn't the first branch to go into the computation. I've tried to remove as much of the obvious vestigial API surface of the old CRTP implementation as I could, but I suspect there is further cleanup that should now be possible, especially around the operand bundle APIs. I'm leaving all of that for future work in this patch as enough things are changing here as-is. One thing that made this harder for me to reason about and debug was the pervasive use of unsigned values in subtraction and other arithmetic computations. I had to debug more than one unintentional wrap. I've switched a few of these to use `int` which seems substantially simpler, but I've held back from doing this more broadly to avoid creating confusing divergence within a single class's API. I also worked to remove all of the magic numbers used to index into operands, putting them behind named constants or putting them into a single method with a comment and strictly using the method elsewhere. This was necessary to be able to re-layout the operands as discussed above. Thanks to Ben for reviewing this (somewhat large and awkward) patch! Differential Revision: https://reviews.llvm.org/D54788 llvm-svn: 347452
* [IR] Add hasNPredecessors, hasNPredecessorsOrMore to BasicBlockVedant Kumar2018-11-192-11/+10
| | | | | | | | | | | | | | | | | | | | | | | Add methods to BasicBlock which make it easier to efficiently check whether a block has N (or more) predecessors. This can be more efficient than using pred_size(), which is a linear time operation. We might consider adding similar methods for successors. I haven't done so in this patch because succ_size() is already O(1). With this patch applied, I measured a 0.065% compile-time reduction in user time for running `opt -O3` on the sqlite3 amalgamation (30 trials). The change in mergeStoreIntoSuccessor alone saves 45 million linked list iterations in a stage2 Release build of llc. See llvm.org/PR39702 for a harder but more general way of achieving similar results. Differential Revision: https://reviews.llvm.org/D54686 llvm-svn: 347256
* [DebugInfo] DISubprogram flags get their own flags word. NFC.Paul Robinson2018-11-194-77/+73
| | | | | | | | | | | | | This will hold flags specific to subprograms. In the future we could potentially free up scarce bits in DIFlags by moving subprogram-specific flags from there to the new flags word. This patch does not change IR/bitcode formats, that will be done in a follow-up. Differential Revision: https://reviews.llvm.org/D54597 llvm-svn: 347239
* [ThinLTO] Fix comment. NFCEugene Leviant2018-11-191-1/+1
| | | | llvm-svn: 347207
* Fix bot failure from r347145Teresa Johnson2018-11-171-8/+7
| | | | | | | | The #if check around the statistics computation gave an error about the statistic being an unused variable. Instead, guard with AreStatisticsEnabled(). llvm-svn: 347146
* [ThinLTO] Add some stats for read only variable internalizationTeresa Johnson2018-11-171-0/+14
| | | | | | | | | | | | | | | Summary: Follow up to D49362 ([ThinLTO] Internalize read only globals). Add a statistic on the number of read only variables (only counting live variables since dead variables will be dropped anyway). Reviewers: evgeny777 Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54642 llvm-svn: 347145
OpenPOWER on IntegriCloud