summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Redefine Freeze instructionaqjune2019-11-125-48/+55
| | | | | | | | | | | | | | | | | | | | Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
* [AArch64][SVE] Spilling/filling of SVE callee-saves.Sander de Smalen2019-11-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the spills/fills of callee-saved SVE registers using STR and LDR instructions. Also adds the `aarch64_sve_vector_pcs` attribute to specify the callee-saved registers to be used for functions that return SVE vectors or take SVE vectors as arguments. The callee-saved registers are vector registers z8-z23 and predicate registers p4-p15. The overal frame-layout with SVE will be as follows: +-------------+ | stack args | +-------------+ | Callee Saves| | X29, X30 | |-------------| <- FP | SVE Callee | < ////////////// | saved regs | < ////////////// | z23 | < ////////////// | : | < // SCALABLE // | z8 | < ////////////// | p15 | < /// STACK //// | : | < ////////////// | p4 | < //// AREA //// +-------------+ < ////////////// | : | < ////////////// | SVE locals | < ////////////// | : | < ////////////// +-------------+ |/////////////| alignment gap. | : | | Stack objs | | : | +-------------+ <- SP after call and frame-setup Reviewers: cameron.mcinally, efriedma, greened, thegameg, ostannard, rengolin Reviewed By: ostannard Differential Revision: https://reviews.llvm.org/D68996
* ThinLTO : Import always_inline functions irrespective of the thresholdTeresa Johnson2019-11-082-1/+2
| | | | | | | | | | | | | | | | Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions. Patch by Bharathi Seshadri <bseshadr@cisco.com> Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70014
* [ThinLTO] Fix bug when importing writeonly variablesevgeny2019-11-081-1/+15
| | | | | | | | Patch enables import of write-only variables with non-trivial initializers to fix linker errors. Initializers of imported variables are converted to 'zeroinitializer' to avoid promotion of referenced objects. Differential revision: https://reviews.llvm.org/D70006
* [CostModel] Fixed isExtractSubvectorMask for undef index off endTim Renouf2019-11-081-1/+1
| | | | | | | | | | | | | | | | | | | ShuffleVectorInst::isExtractSubvectorMask, introduced in [CostModel] Add SK_ExtractSubvector handling to getInstructionThroughput (PR39368) erroneously thought that %340 = shufflevector <4 x float> %339, <4 x float> undef, <3 x i32> <i32 2, i32 3, i32 undef> is a subvector extract, even though it goes off the end of the parent vector with the undef index. That then caused an assert in BasicTTIImplBase::getExtractSubvectorOverhead. This commit fixes that, by not considering the above a subvector extract. Differential Revision: https://reviews.llvm.org/D70005 Change-Id: I87b8b00b24bef19ffc9a1b82ef4eca3b8a246eaf
* [NFC] ConstantRange::subWithNoWrap(): fixup commentRoman Lebedev2019-11-081-1/+1
|
* [ConstantRange] Add umul_sat()/smul_sat() methodsRoman Lebedev2019-11-081-0/+35
| | | | | | | | | | | | | | | | | | | | | | | Summary: To be used in `ConstantRange::mulWithNoOverflow()`, may in future be useful for when saturating shift/mul ops are added. These are precise as far as i can tell. I initially though i will need `APInt::[us]mul_sat()` for these, but it turned out much simpler to do what `ConstantRange::multiply()` does - perform multiplication in twice the bitwidth, and then truncate. Though here we want saturating signed truncation. Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69994
* [CR] ConstantRange::sshl_sat(): check sigdness of the min/max, not rangesRoman Lebedev2019-11-081-2/+2
| | | | | This was pointed out in review, but forgot to stage this change into the commit itself..
* [ConstantRange] Add `ushl_sat()`/`sshl_sat()` methods.Roman Lebedev2019-11-081-0/+20
| | | | | | | | | | | | | | | | | | Summary: To be used in `ConstantRange::shlWithNoOverflow()`, may in future be useful for when saturating shift/mul ops are added. Unlike `ConstantRange::shl()`, these are precise. Reviewers: nikic, spatel, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69960
* [AsmWritter] Fixed "null check after dereferencing" warningDávid Bolvanský2019-11-071-4/+2
| | | | | | | | | | | | Summary: The 'BB->getParent()' pointer was utilized before it was verified against nullptr. Check lines: 3567, 3581. Reviewers: jyknight, RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69751
* [ConstantRange][LVI] Use overflow flags from `sub` to constrain the rangeRoman Lebedev2019-11-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This notably improves non-negativity deduction: ``` | statistic | old | new | delta | % change | | correlated-value-propagation.NumAShrs | 209 | 227 | 18 | 8.6124% | | correlated-value-propagation.NumAddNSW | 4972 | 4988 | 16 | 0.3218% | | correlated-value-propagation.NumAddNUW | 7141 | 7148 | 7 | 0.0980% | | correlated-value-propagation.NumAddNW | 12113 | 12136 | 23 | 0.1899% | | correlated-value-propagation.NumAnd | 442 | 445 | 3 | 0.6787% | | correlated-value-propagation.NumNSW | 7160 | 7176 | 16 | 0.2235% | | correlated-value-propagation.NumNUW | 13306 | 13316 | 10 | 0.0752% | | correlated-value-propagation.NumNW | 20466 | 20492 | 26 | 0.1270% | | correlated-value-propagation.NumSDivs | 207 | 212 | 5 | 2.4155% | | correlated-value-propagation.NumSExt | 6279 | 6679 | 400 | 6.3704% | | correlated-value-propagation.NumSRems | 28 | 29 | 1 | 3.5714% | | correlated-value-propagation.NumShlNUW | 2793 | 2796 | 3 | 0.1074% | | correlated-value-propagation.NumShlNW | 3964 | 3967 | 3 | 0.0757% | | correlated-value-propagation.NumUDivs | 353 | 358 | 5 | 1.4164% | | instcount.NumAShrInst | 13763 | 13741 | -22 | -0.1598% | | instcount.NumAddInst | 277349 | 277348 | -1 | -0.0004% | | instcount.NumLShrInst | 27437 | 27463 | 26 | 0.0948% | | instcount.NumOrInst | 102677 | 102678 | 1 | 0.0010% | | instcount.NumSDivInst | 8732 | 8727 | -5 | -0.0573% | | instcount.NumSExtInst | 80872 | 80468 | -404 | -0.4996% | | instcount.NumSRemInst | 1679 | 1678 | -1 | -0.0596% | | instcount.NumTruncInst | 62154 | 62153 | -1 | -0.0016% | | instcount.NumUDivInst | 2526 | 2527 | 1 | 0.0396% | | instcount.NumURemInst | 1589 | 1590 | 1 | 0.0629% | | instcount.NumZExtInst | 69405 | 69809 | 404 | 0.5821% | | instcount.TotalInsts | 7439575 | 7439574 | -1 | 0.0000% | ``` Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69942
* [ThinLTO] Import readonly vars with refsevgeny2019-11-071-2/+20
| | | | | | Patch allows importing declarations of functions and variables, referenced by the initializer of some other readonly variable. Differential revision: https://reviews.llvm.org/D69561
* Keep import function list for inlinee profile updateWenlei He2019-11-061-0/+5
| | | | | | | | | | | | | Summary: When adjusting function entry counts after inlining, Funciton::setEntryCount is called without providing an import function list. The side effect of that is the previously set import function list will be dropped. The import function list is used by ThinLTO to help import hot cross module callee for LTO inlining, so dropping that during ThinLTO pre-link may adversely affect LTO inlining. The fix is to keep the list while updating entry counts for inlining. Reviewers: wmi, davidxl, tejohnson Subscribers: mehdi_amini, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69736
* [ConstantRange] Add `subWithNoWrap()` methodRoman Lebedev2019-11-071-0/+30
| | | | | | | | | | | | | | | | | | | | | Summary: Much like D67339, adds ConstantRange handling for when we know no-wrap behavior of the `sub`. Unlike addWithNoWrap(), we only get lucky re returning empty set for signed wrap. For unsigned, we must perform overflow check manually. A patch that makes use of this in LVI (CVP) to be posted later. Reviewers: nikic, shchenz, efriedma Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69918
* [ConstantRange] Cleanup addWithNoWrap() by just piggybacking on ↵Roman Lebedev2019-11-071-32/+8
| | | | | | | | | sadd_sat()/uadd_sat() As discussed in https://reviews.llvm.org/D69918 that happens to work as intended, and returns empty set if there is always an overflow because we get lucky with intersection. Since there's now an explicit test for that, let's prefer cleaner code.
* [IR] Remove switch's default block that causes clang 8 raise erroraqjune2019-11-051-2/+0
|
* [IR] Add Freeze instructionaqjune2019-11-055-29/+50
| | | | | | | | | | | | | | | | | | Summary: - Define Instruction::Freeze, let it be UnaryOperator - Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter The format is `%x = freeze <ty> %v` - Add support for freeze instruction to llvm-c interface. - Add m_Freeze in PatternMatch. - Erase freeze when lowering IR to SelDag. Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark Reviewed By: lebedev.ri, jdoerfert Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits Differential Revision: https://reviews.llvm.org/D29011
* [IR] adjust assert when replacing undef elements in vector constantSanjay Patel2019-11-041-1/+1
| | | | | | | | | | As noted in follow-up to: rGa1e8ad4f2fa7 It's not safe to assume that an element of the constant is always non-null. It's definitely not an expected case for the current instcombine user, but that may not hold if this function is eventually called from arbitrary places.
* [DebugInfo] Fix for DW_OP_LLVM_fragment in DIExpression::isImplicit()Bjorn Pettersson2019-11-031-9/+16
| | | | | | | | | | | DIExpression::isImplicit() did not handle DW_OP_LLVM_fragment correctly. It was scanning the elements in the expression by iterating from the end. But we do not know the position of ops unless we iterate from the beginning of the expression, since DW_OP:s and their operands are stored flat in the expression list. The old code also assumed that a DW_OP_LLVM_fragment only occupied one element in the expression list, but it actually occupies three elements.
* [LegacyPassManager] Fixed "null check after derefencing" warningDávid Bolvanský2019-11-021-2/+1
| | | | The 'RequiredPass' pointer was utilized before it was verified against nullptr. Check lines: 1626, 1629.
* NoFree argument attribute.Stefan Stipanovic2019-11-021-3/+3
| | | | | | | | | | | | Summary: Deducing nofree atrribute for function arguments. Reviewers: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67886
* Revert "NoFree argument attribute."Stefan Stipanovic2019-11-021-3/+3
| | | | This reverts commit c12efa2ed0547f7f9f8fba0ad7a76a4cb08bf53a.
* NoFree argument attribute.Stefan Stipanovic2019-11-021-3/+3
| | | | | | | | | | | | Summary: Deducing nofree atrribute for function arguments. Reviewers: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67886
* [LegacyPM] Fix pass structure dumpingevgeny2019-11-011-0/+5
| | | | | | | | If module pass uses on-demand function analyses then structure is being displayed incorrectly because FunctionPassManagerImpl can't dump contained FPPassManager instances. Differential revision: https://reviews.llvm.org/D69315
* [LegacyPassManager] Delete BasicBlockPass/Manager.Alina Sbirlea2019-10-304-307/+2
| | | | | | | | | | | | | | | | Summary: Delete the BasicBlockPass and BasicBlockManager, all its dependencies and update documentation. The BasicBlockManager was improperly tested and found to be potentially broken, and was deprecated as of rL373254. In light of the switch to the new pass manager coming before the next release, this patch is a first cleanup of the LegacyPassManager. Reviewers: chandlerc, echristo Subscribers: mehdi_amini, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69121
* [IR] move/change null-check to assertSanjay Patel2019-10-291-1/+2
| | | | | | | This should trigger a dereference before null-check warning, but I don't see it when building with clang. In any case, the current and known future users of this helper require non-null args, so I'm converting the 'if' to an assert.
* [IR] move helper function to replace undef constant (elements) with fixed ↵Sanjay Patel2019-10-291-4/+25
| | | | | | | | constants This is the NFC part of D69519. We had this functionality locally in instcombine, but it can be used elsewhere, so hoisting it to Constant class.
* [ConstantFold] Push extractelement into getelementptr's operandsJay Foad2019-10-291-1/+1
| | | | | | This fixes a minor oversight mentioned in the review of D69379: we should push extractelement into the operands of getelementptr regardless of whether that enables further folding.
* [Remarks] Emit the remarks section by default for certain formatsFrancis Visoiu Mistrih2019-10-281-0/+32
| | | | | | | | | Emit a remarks section by default for the following formats: * bitstream * yaml-strtab while still providing -remarks-section=<bool> to override the defaults.
* [ConstantFold] Fold extractelement of getelementptrJay Foad2019-10-281-6/+29
| | | | | | | | | | | | | | Summary: Getelementptr has vector type if any of its operands are vectors (the scalar operands being implicitly broadcast to all vector elements). Extractelement applied to a vector getelementptr can be folded by applying the extractelement in turn to all of the vector operands. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69379
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-283-3/+15
| | | | | | | | | | | | | | | | | | | Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
* [Alignment][NFC] Convert AllocaInst to MaybeAlignGuillaume Chatelet2019-10-251-13/+14
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Reviewed By: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69301
* [ObjC][ARC] Check whether the return and parameter types of the old andAkira Hatanaka2019-10-241-1/+22
| | | | | | | | | | | | new functions are compatible before upgrading a function call to an intrinsic call. Sometimes users insert calls to ARC runtime functions that are not compatible with the corresponding intrinsic functions (for example, 'i8* @objc_storeStrong' instead of 'void @objc_storeStrong'). Don't upgrade those calls. rdar://problem/56447127
* [LVI][CVP] LazyValueInfoImpl::solveBlockValueBinaryOp(): use no-wrap flags ↵Roman Lebedev2019-10-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from `add` op Summary: This was suggested in https://reviews.llvm.org/D69277#1717210 In this form (this is what was suggested, right?), the results aren't staggering (especially since given LVI cross-block focus) this does catch some things (as per test-suite), but not too much: | statistic | old | new | delta | % change | | correlated-value-propagation.NumAddNSW | 4981 | 4982 | 1 | 0.0201% | | correlated-value-propagation.NumAddNW | 12125 | 12126 | 1 | 0.0082% | | correlated-value-propagation.NumCmps | 1199 | 1202 | 3 | 0.2502% | | correlated-value-propagation.NumDeadCases | 112 | 111 | -1 | -0.8929% | | correlated-value-propagation.NumMulNSW | 275 | 278 | 3 | 1.0909% | | correlated-value-propagation.NumMulNUW | 1323 | 1326 | 3 | 0.2268% | | correlated-value-propagation.NumMulNW | 1598 | 1604 | 6 | 0.3755% | | correlated-value-propagation.NumNSW | 7158 | 7167 | 9 | 0.1257% | | correlated-value-propagation.NumNUW | 13304 | 13310 | 6 | 0.0451% | | correlated-value-propagation.NumNW | 20462 | 20477 | 15 | 0.0733% | | correlated-value-propagation.NumOverflows | 4 | 7 | 3 | 75.0000% | | correlated-value-propagation.NumPhis | 15366 | 15381 | 15 | 0.0976% | | correlated-value-propagation.NumSExt | 6273 | 6277 | 4 | 0.0638% | | correlated-value-propagation.NumShlNSW | 1172 | 1171 | -1 | -0.0853% | | correlated-value-propagation.NumShlNUW | 2793 | 2794 | 1 | 0.0358% | | correlated-value-propagation.NumSubNSW | 730 | 736 | 6 | 0.8219% | | correlated-value-propagation.NumSubNUW | 2044 | 2046 | 2 | 0.0978% | | correlated-value-propagation.NumSubNW | 2774 | 2782 | 8 | 0.2884% | | instcount.NumAddInst | 277586 | 277569 | -17 | -0.0061% | | instcount.NumAndInst | 66056 | 66054 | -2 | -0.0030% | | instcount.NumBrInst | 709147 | 709146 | -1 | -0.0001% | | instcount.NumCallInst | 528579 | 528576 | -3 | -0.0006% | | instcount.NumExtractValueInst | 18307 | 18301 | -6 | -0.0328% | | instcount.NumOrInst | 102660 | 102665 | 5 | 0.0049% | | instcount.NumPHIInst | 318008 | 318007 | -1 | -0.0003% | | instcount.NumSelectInst | 46373 | 46370 | -3 | -0.0065% | | instcount.NumSExtInst | 79496 | 79488 | -8 | -0.0101% | | instcount.NumShlInst | 40654 | 40657 | 3 | 0.0074% | | instcount.NumTruncInst | 62251 | 62249 | -2 | -0.0032% | | instcount.NumZExtInst | 68211 | 68221 | 10 | 0.0147% | | instcount.TotalBlocks | 843910 | 843909 | -1 | -0.0001% | | instcount.TotalInsts | 7387448 | 7387423 | -25 | -0.0003% | Reviewers: nikic, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69321
* [Alignment][NFC] Convert StoreInst to MaybeAlignGuillaume Chatelet2019-10-221-22/+18
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69303 llvm-svn: 375499
* [Alignment][NFC] Convert LoadInst to MaybeAlignGuillaume Chatelet2019-10-221-9/+10
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69302 llvm-svn: 375498
* [Alignment][NFC] Use MaybeAlign in AttrBuilderGuillaume Chatelet2019-10-221-5/+7
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
* [Alignment][NFC] Attributes use Align/MaybeAlignGuillaume Chatelet2019-10-222-23/+20
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
* [IR] Fix mayReadFromMemory() for writeonly callsYevgeny Rouban2019-10-211-1/+1
| | | | | | | | | | | | | | Current implementation of Instruction::mayReadFromMemory() returns !doesNotAccessMemory() which is !ReadNone. This does not take into account that the writeonly attribute also indicates that the call does not read from memory. The patch changes the predicate to !doesNotReadMemory() that reflects the intended behavior. Differential Revision: https://reviews.llvm.org/D69086 llvm-svn: 375389
* [ConstantRange] makeGuaranteedNoWrapRegion(): `shl` supportRoman Lebedev2019-10-201-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If all the shifts amount are already poison-producing, then we can add more poison-producing flags ontop: https://rise4fun.com/Alive/Ocwi Otherwise, we should only consider the possible range of shift amts that don't result in poison. For unsigned range not not overflow, we must not shift out any set bits, and the actual limit for `x` can be computed by backtransforming the maximal value we could ever get out of the `shl` - `-1` through `lshr`. If the `x` is any larger than that then it will overflow. Likewise for signed range, but just in signed domain.. This is based on the general idea outlined by @nikic in https://reviews.llvm.org/D68672#1714990 Reviewers: nikic, sanjoy Reviewed By: nikic Subscribers: hiraditya, llvm-commits, nikic Tags: #llvm Differential Revision: https://reviews.llvm.org/D69217 llvm-svn: 375370
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-171-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 375094
* [SVE][IR] Small TypeSize improvements left out of initial commitGraham Hunter2019-10-161-4/+4
| | | | | | | The commit for D53137 left out the last round of improvements requested by reviewers. Adding those in now. llvm-svn: 375013
* [Alignment][NFC] Value::getPointerAlignment returns MaybeAlignGuillaume Chatelet2019-10-152-30/+30
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68398 llvm-svn: 374889
* [Alignment] Migrate Attribute::getWith(Stack)AlignmentGuillaume Chatelet2019-10-153-15/+15
| | | | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
* [DebugInfo] Add a DW_OP_LLVM_entry_value operationDavid Stenberg2019-10-152-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Internally in LLVM's metadata we use DW_OP_entry_value operations with the same semantics as DWARF; that is, its operand specifies the number of bytes that the entry value covers. At the time of emitting entry values we don't know the emitted size of the DWARF expression that the entry value will cover. Currently the size is hardcoded to 1 in DIExpression, and other values causes the verifier to fail. As the size is 1, that effectively means that we can only have valid entry values for registers that can be encoded in one byte, which are the registers with DWARF numbers 0 to 31 (as they can be encoded as single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump will print an operation "correctly", even if the byte size is less than that, which may make it seem that we emit correct DWARF for registers with DWARF numbers > 31. If you instead use readelf for such cases, it will interpret the number of specified bytes as a DWARF expression. This seems like a limitation in llvm-dwarfdump. As suggested in D66746, a way forward would be to add an internal variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand instead specifies the number of operations that the entry value covers, and we then translate that into the byte size at the time of emission. In this patch that internal operation is added. This patch keeps the limitation that a entry value can only be applied to simple register locations, but it will fix the issue with the size operand being incorrect for DWARF numbers > 31. Reviewers: aprantl, vsk, djtodoro, NikolaPrica Reviewed By: aprantl Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67492 llvm-svn: 374881
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-153-3/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-141-18/+0
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* [ThinLTO] Fix printing of NoInline function summary flagTeresa Johnson2019-10-141-1/+1
| | | | | | | | | | | | | | | | Summary: The guard for printing function flags in the summary was not checking the NoInline flag. Reviewers: wmi Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68948 llvm-svn: 374802
* [ConstantFold] fix inconsistent handling of extractelement with undef index ↵Sanjay Patel2019-10-131-6/+3
| | | | | | | | | (PR42689) Any constant other than zero was already folded to undef if the index is undef. https://bugs.llvm.org/show_bug.cgi?id=42689 llvm-svn: 374729
* Fix compilation warnings. NFC.Michael Liao2019-10-111-1/+1
| | | | llvm-svn: 374554
OpenPOWER on IntegriCloud