summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Use Align for TFL::TransientStackAlignmentGuillaume Chatelet2019-10-2113-14/+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 Subscribers: arsenm, dschuff, jyknight, sdardis, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69216 llvm-svn: 375398
* [NFC][InstCombine] Fixup commentsRoman Lebedev2019-10-211-2/+2
| | | | | | As noted in post-commit review of rL375378375378. llvm-svn: 375397
* [CVP] Deduce no-wrap on `mul`Roman Lebedev2019-10-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `ConstantRange::makeGuaranteedNoWrapRegion()` knows how to deal with `mul` since rL335646, there is exhaustive test coverage. This is already used by CVP's `processOverflowIntrinsic()`, and by SCEV's `StrengthenNoWrapFlags()` That being said, currently, this doesn't help much in the end: | statistic | old | new | delta | percentage | | correlated-value-propagation.NumMulNSW | 4 | 275 | 271 | 6775.00% | | correlated-value-propagation.NumMulNUW | 4 | 1323 | 1319 | 32975.00% | | correlated-value-propagation.NumMulNW | 8 | 1598 | 1590 | 19875.00% | | correlated-value-propagation.NumNSW | 5715 | 5986 | 271 | 4.74% | | correlated-value-propagation.NumNUW | 9193 | 10512 | 1319 | 14.35% | | correlated-value-propagation.NumNW | 14908 | 16498 | 1590 | 10.67% | | instcount.NumAddInst | 275871 | 275869 | -2 | 0.00% | | instcount.NumBrInst | 708234 | 708232 | -2 | 0.00% | | instcount.NumMulInst | 43812 | 43810 | -2 | 0.00% | | instcount.NumPHIInst | 316786 | 316784 | -2 | 0.00% | | instcount.NumTruncInst | 62165 | 62167 | 2 | 0.00% | | instcount.NumUDivInst | 2528 | 2526 | -2 | -0.08% | | instcount.TotalBlocks | 842995 | 842993 | -2 | 0.00% | | instcount.TotalInsts | 7376486 | 7376478 | -8 | 0.00% | (^ test-suite plain, tests still pass) Reviewers: nikic, reames, luqmana, sanjoy, timshen Reviewed By: reames Subscribers: hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69203 llvm-svn: 375396
* [InstCombine] Allow values with multiple users in SimplifyDemandedVectorEltsPiotr Sobczak2019-10-213-27/+115
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow for ignoring the check for a single use in SimplifyDemandedVectorElts to be able to simplify operands if DemandedElts is known to contain the union of elements used by all users. It is a responsibility of a caller of SimplifyDemandedVectorElts to supply correct DemandedElts. Simplify a series of extractelement instructions if only a subset of elements is used. Reviewers: reames, arsenm, majnemer, nhaehnle Reviewed By: nhaehnle Subscribers: wdng, jvesely, nhaehnle, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67345 llvm-svn: 375395
* [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
* [BPF] fix indirect call assembly codeYonghong Song2019-10-211-1/+1
| | | | | | | | | | | | | Currently, for indirect call, the assembly code printed out as callx <imm> This is not right, it should be callx <reg> Fixed the issue with proper format. Differential Revision: https://reviews.llvm.org/D69229 llvm-svn: 375386
* [Attributor][FIX] Silence sign-compare warningJohannes Doerfert2019-10-211-1/+1
| | | | llvm-svn: 375384
* [Attributor] Teach AANoCapture to use information in-flight more aggressivelyJohannes Doerfert2019-10-211-8/+63
| | | | | | | | | AAReturnedValues, AAMemoryBehavior, and AANoUnwind, can provide information that helps during the tracking or even justifies no-capture. We now use this information and enable no-capture in some test cases designed a long while a ago for these cases. llvm-svn: 375382
* [X86] Check Subtarget.hasSSE3() before calling shouldUseHorizontalOp and ↵Craig Topper2019-10-201-1/+1
| | | | | | | | | | emitting X86ISD::FHADD in LowerUINT_TO_FP_i64. This was a regression from r375341. Fixes PR43729. llvm-svn: 375381
* [IndVars] Add a todo to reflect a further oppurtunity identified in D69009Philip Reames2019-10-201-0/+7
| | | | | | Nikita pointed out an oppurtunity, might as well document it in the code. llvm-svn: 375380
* [IndVars] Eliminate loop exits with equivalent exit countsPhilip Reames2019-10-201-4/+28
| | | | | | | | | | | | We can end up with two loop exits whose exit counts are equivalent, but whose textual representation is different and non-obvious. For the sub-case where we have a series of exits which dominate one another (common), eliminate any exits which would iterate *after* a previous exit on the exiting iteration. As noted in the TODO being removed, I'd always thought this was a good idea, but I've now seen this in a real workload as well. Interestingly, in review, Nikita pointed out there's let another oppurtunity to leverage SCEV's reasoning. If we kept track of the min of dominanting exits so far, we could discharge exits with EC >= MDE. This is less powerful than the existing transform (since later exits aren't considered), but potentially more powerful for any case where SCEV can prove a >= b, but neither a == b or a > b. I don't have an example to illustrate that oppurtunity, but won't be suprised if we find one and return to handle that case as well. Differential Revision: https://reviews.llvm.org/D69009 llvm-svn: 375379
* [InstCombine] conditional sign-extend of high-bit-extract: 'or' pattern.Roman Lebedev2019-10-203-18/+23
| | | | | | | | | | | | | | In this pattern, all the "magic" bits that we'd `add` are all high sign bits, and in the value we'd be adding to they are all unset, not unexpectedly, so we can have an `or` there: https://rise4fun.com/Alive/ups It is possible that `haveNoCommonBitsSet()` should be taught about this pattern so that we never have an `add` variant, but the reasoning would need to be recursive (because of that `select`), so i'm not really sure that would be worth it just yet. llvm-svn: 375378
* Reverted r375254 as it has broken some build bots for a long time.Vladimir Vereschaka2019-10-206-192/+18
| | | | llvm-svn: 375375
* [InstCombine] Fold uadd.sat(a, b) == 0 and usub.sat(a, b) == 0Nikita Popov2019-10-201-0/+22
| | | | | | | | | | | | | This adds folds for comparing uadd.sat/usub.sat with zero: * uadd.sat(a, b) == 0 => a == 0 && b == 0 => (a | b) == 0 * usub.sat(a, b) == 0 => a <= b And inverted forms for !=. Differential Revision: https://reviews.llvm.org/D69224 llvm-svn: 375374
* Fix buildbot error in SIRegisterInfo.cpp.Zinovy Nis2019-10-201-3/+4
| | | | llvm-svn: 375373
* [InstCombine] Shift amount reassociation in shifty sign bit test (PR43595)Roman Lebedev2019-10-203-26/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This problem consists of several parts: * Basic sign bit extraction - `trunc? (?shr %x, (bitwidth(x)-1))`. This is trivial, and easy to do, we have a fold for it. * Shift amount reassociation - if we have two identical shifts, and we can simplify-add their shift amounts together, then we likely can just perform them as a single shift. But this is finicky, has one-use restrictions, and shift opcodes must be identical. But there is a super-pattern where both of these work together. to produce sign bit test from two shifts + comparison. We do indeed already handle this in most cases. But since we get that fold transitively, it has one-use restrictions. And what's worse, in this case the right-shifts aren't required to be identical, and we can't handle that transitively: If the total shift amount is bitwidth-1, only a sign bit will remain in the output value. But if we look at this from the perspective of two shifts, we can't fold - we can't possibly know what bit pattern we'd produce via two shifts, it will be *some* kind of a mask produced from original sign bit, but we just can't tell it's shape: https://rise4fun.com/Alive/cM0 https://rise4fun.com/Alive/9IN But it will *only* contain sign bit and zeros. So from the perspective of sign bit test, we're good: https://rise4fun.com/Alive/FRz https://rise4fun.com/Alive/qBU Superb! So the simplest solution is to extend `reassociateShiftAmtsOfTwoSameDirectionShifts()` to also have a sudo-analysis mode that will ignore extra-uses, and will only check whether a) those are two right shifts and b) they end up with bitwidth(x)-1 shift amount and return either the original value that we sign-checking, or null. This does not have any functionality change for the existing `reassociateShiftAmtsOfTwoSameDirectionShifts()`. All that being said, as disscussed in the review, this yet again increases usage of instsimplify in instcombine as utility. Some day that may need to be reevaluated. https://bugs.llvm.org/show_bug.cgi?id=43595 Reviewers: spatel, efriedma, vsk Reviewed By: spatel Subscribers: xbolva00, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68930 llvm-svn: 375371
* [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
* AMDGPU: Increase vcc liveness scan thresholdMatt Arsenault2019-10-201-2/+4
| | | | | | | Avoids a test regression in a future patch. Also add debug printing on this case, so I waste less time debugging folds in the future. llvm-svn: 375367
* AMDGPU: Split flat offsets that don't fit in DAGMatt Arsenault2019-10-203-3/+96
| | | | | | | | | | We handle it this way for some other address spaces. Since r349196, SILoadStoreOptimizer has been trying to do this. This is after SIFoldOperands runs, which can change the addressing patterns. It's simpler to just split this earlier. llvm-svn: 375366
* AMDGPU: Fix missing OPERAND_IMMEDIATEMatt Arsenault2019-10-201-12/+13
| | | | llvm-svn: 375365
* AMDGPU: Don't re-get the subtargetMatt Arsenault2019-10-201-21/+9
| | | | | | It's already available in the class. llvm-svn: 375363
* [yaml2obj][obj2yaml] - Do not create a symbol table by default.George Rimar2019-10-201-6/+23
| | | | | | | | | | | | | | | | | | This patch tries to resolve problems faced in D68943 and uses some of the code written by Konrad Wilhelm Kleine in that patch. Previously, yaml2obj tool always created a .symtab section. This patch changes that. With it we only create it when have a "Symbols:" tag in the YAML document or when we need to create it because it is used by another section(s). obj2yaml follows the new behavior and does not print "Symbols:" anymore when there is no symbol table. Differential revision: https://reviews.llvm.org/D69041 llvm-svn: 375361
* Fix minor warning in DWARFVerifier.Zinovy Nis2019-10-201-2/+2
| | | | llvm-svn: 375357
* AMDGPU: Don't error on calls to null or undefMatt Arsenault2019-10-201-0/+9
| | | | | | Calls to constants should probably be generally handled. llvm-svn: 375356
* [SCEV] Simplify umin/max of zext and sext of the same valuePhilip Reames2019-10-191-1/+34
| | | | | | | | This is a common idiom which arises after induction variables are widened, and we have two or more exit conditions. Interestingly, we don't have instcombine or instsimplify support for this either. Differential Revision: https://reviews.llvm.org/D69006 llvm-svn: 375349
* [X86] Pulled out helper to decode target shuffle element sentinel values to ↵Simon Pilgrim2019-10-191-13/+22
| | | | | | | | 'Zeroable' known undef/zero bits. NFCI. Renamed 'resolveTargetShuffleAndZeroables' to 'resolveTargetShuffleFromZeroables' to match. llvm-svn: 375348
* [TargetLowering][DAGCombine][MSP430] add/use hook for Shift Amount Threshold ↵Sanjay Patel2019-10-193-12/+19
| | | | | | | | | | | | | | | | | (1/2) Provides a TLI hook to allow targets to relax the emission of shifts, thus enabling codegen improvements on targets with no multiple shift instructions and cheap selects or branches. Contributes to a Fix for PR43559: https://bugs.llvm.org/show_bug.cgi?id=43559 Patch by: @joanlluch (Joan LLuch) Differential Revision: https://reviews.llvm.org/D69116 llvm-svn: 375347
* [X86][SSE] lowerV16I8Shuffle - tryToWidenViaDuplication - undef unpack argsSimon Pilgrim2019-10-191-1/+9
| | | | | | tryToWidenViaDuplication lowers using the shuffle_v8i16(unpack_v16i8(shuffle_v8i16(x),shuffle_v8i16(x))) pattern, but the unpack only needs the even/odd 16i8 args if the original v16i8 shuffle mask references the even/odd elements - which isn't true for many extension style shuffles. llvm-svn: 375342
* [X86][SSE] LowerUINT_TO_FP_i64 - only use HADDPD for size/fast-hopsSimon Pilgrim2019-10-191-12/+11
| | | | | | | | We were always generating a single source HADDPD, but really we should only do this if shouldUseHorizontalOp says its a good idea. Differential Revision: https://reviews.llvm.org/D69175 llvm-svn: 375341
* Avoid including CodeView/SymbolRecord.h from MCStreamer.hReid Kleckner2019-10-194-20/+23
| | | | | | Move the types needed out so they can be forward declared instead. llvm-svn: 375325
* Prune a LegacyDivergenceAnalysis and MachineLoopInfo include eachReid Kleckner2019-10-1923-4/+28
| | | | | | Now X86ISelLowering doesn't depend on many IR analyses. llvm-svn: 375320
* Prune Analysis includes from SelectionDAG.hReid Kleckner2019-10-1910-17/+19
| | | | | | Only forward declarations are needed here. Follow-on to r375311. llvm-svn: 375319
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-193-2/+5
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* Prune two MachineInstr.h includes, fix up depsReid Kleckner2019-10-1918-11/+38
| | | | | | | | | | MachineInstr.h included AliasAnalysis.h, which includes a world of IR constructs mostly unneeded in CodeGen. Prune it. Same for DebugInfoMetadata.h. Noticed with -ftime-trace. llvm-svn: 375311
* LiveIntervals: Fix handleMoveUp with subreg def moving across a defMatt Arsenault2019-10-181-1/+16
| | | | | | | | | If a subregister def was moved across another subregister def and another use, the main range was not correctly updated. The end point of the moved interval ended too early and missed the use from theh other lanes in the subreg def. llvm-svn: 375300
* [AMDGPU] move PHI nodes to AGPR classStanislav Mekhanoshin2019-10-181-5/+16
| | | | | | | | | If all uses of a PHI are in AGPR register class we should avoid unneeded copies via VGPRs. Differential Revision: https://reviews.llvm.org/D69200 llvm-svn: 375297
* [SampleFDO] Add profile remapping support for profile on-demand loading usedWei Mi2019-10-182-52/+87
| | | | | | | | | | | | | | | | | | | | by ExtBinary format profile Profile on-demand loading was added for ExtBinary format profile in rL374233, but currently profile on-demand loading doesn't work well with profile remapping. The patch adds the support. Suppose a function in the current module has outline instance in the profile. The function name in the module is different from the name of the outline instance, but remapper knows the two names are equal. When loading profile on-demand, the outline instance has to be loaded with remapper's help. At the same time SampleProfileReaderItaniumRemapper is changed from a proxy of SampleProfileReader to a helper member in SampleProfileReader. Differential Revision: https://reviews.llvm.org/D68901 llvm-svn: 375295
* [AMDGPU] Remove -amdgpu-spill-sgpr-to-smem.Jay Foad2019-10-182-156/+1
| | | | | | | | | | | | | | Summary: The implementation was never completed and never used except in tests. Reviewers: arsenm, mareko Subscribers: qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69163 llvm-svn: 375293
* [CVP] setDeducedOverflowingFlags(): actually inc per-opcode statsRoman Lebedev2019-10-181-4/+4
| | | | | | | This is really embarrassing. Those are pointers, so that offsets the pointers, not the statistics pointed-by the pointer... llvm-svn: 375290
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-182-1/+16
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* [X86] Fix register parsing in .seh_* in Intel syntaxReid Kleckner2019-10-181-4/+3
| | | | | | | | | | Previously, the parser checked for a '%' prefix to indicate a register. In Intel syntax mode, LLVM does not print a '%' prefix on registers, so LLVM could not parse its own assembly output. Instead, require that register numbers be integer literals, or at least start with an integer literal, which is consistent with .cfi_* directive register parsing. llvm-svn: 375287
* [WebAssembly] Allow multivalue signatures in object filesThomas Lively2019-10-183-14/+7
| | | | | | | | | | | | | | | | | Summary: Also changes the wasm YAML format to reflect the possibility of having multiple return types and to put the returns after the params for consistency with the binary encoding. Reviewers: aheejin, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69156 llvm-svn: 375283
* [GISel][CallLowering] Make isIncomingArgumentHandler a pure virtual methodQuentin Colombet2019-10-184-0/+8
| | | | | | | | | | | | | The default implementation of isIncomingArgumentHandler could lead to generating incorrect code. Make it a pure virtual method, so that targets know they have to override it to produce correct code. NFC Differential Revision: https://reviews.llvm.org/D69187 llvm-svn: 375277
* [CVP] After proving that @llvm.with.overflow()/@llvm.sat() don't overflow, ↵Roman Lebedev2019-10-181-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | also try to prove other no-wrap Summary: CVP, unlike InstCombine, does not run till exaustion. It only does a single pass. When dealing with those special binops, if we prove that they can safely be demoted into their usual binop form, we do set the no-wrap we deduced. But when dealing with usual binops, we try to deduce both no-wraps. So if we convert e.g. @llvm.uadd.with.overflow() to `add nuw`, we won't attempt to check whether it can be `add nuw nsw`. This patch proposes to call `processBinOp()` on newly-created binop, which is identical to what we do for div/rem already. Reviewers: nikic, spatel, reames Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69183 llvm-svn: 375273
* AMDGPU: Relax 32-bit SGPR register classMatt Arsenault2019-10-186-34/+39
| | | | | | | | | | | Mostly use SReg_32 instead of SReg_32_XM0 for arbitrary values. This will allow the register coalescer to do a better job eliminating copies to m0. For GlobalISel, as a terrible hack, use SGPR_32 for things that should use SCC until booleans are solved. llvm-svn: 375267
* AMDGPU: Fix SMEM WAR hazard for gfx10 readlaneAustin Kerbow2019-10-181-0/+1
| | | | | | | | | | | | | | | | Summary: Hazard recognizer fails to see hazard with V_READLANE_B32_gfx10. Reviewers: rampitec Reviewed By: rampitec Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69172 llvm-svn: 375265
* [PGO][PGSO] SizeOpts changes.Hiroshi Yamauchi2019-10-186-18/+192
| | | | | | | | | | | | | | | | | Summary: (Split of off D67120) SizeOpts/MachineSizeOpts changes for profile guided size optimization. Reviewers: davidxl Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69070 llvm-svn: 375254
* [X86] combineX86ShufflesRecursively - pull out isTargetShuffleVariableMask. ↵Simon Pilgrim2019-10-181-1/+2
| | | | | | NFCI. llvm-svn: 375253
* Update MinidumpYAML to use minidump::Exception for exception streamJoseph Tremoulet2019-10-182-2/+67
| | | | | | | | | | | | | | Reviewers: labath, jhenderson, clayborg, MaskRay, grimar Reviewed By: grimar Subscribers: lldb-commits, grimar, MaskRay, hiraditya, llvm-commits Tags: #llvm, #lldb Differential Revision: https://reviews.llvm.org/D68657 llvm-svn: 375242
* [AMDGPU][MC][GFX10] Added sdwa/dpp versions of v_cndmask_b32Dmitry Preobrazhensky2019-10-182-52/+80
| | | | | | | | | | See https://bugs.llvm.org/show_bug.cgi?id=43608 Reviewers: arsenm, rampitec Differential Revision: https://reviews.llvm.org/D69096 llvm-svn: 375241
OpenPOWER on IntegriCloud