summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove ';' after namespace's closing bracket [NFC]David Stenberg2019-06-131-1/+1
| | | | llvm-svn: 363267
* [FIX] Forces shrink wrapping to consider any memory access as aliasing with ↵Diogo N. Sampaio2019-06-131-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
* Extra error checking to ARMAttributeParserEugene Leviant2019-06-131-0/+6
| | | | | | The patch checks for subsection length as discussed in D63191 llvm-svn: 363260
* [NFC] Sink a function call into LiveDebugValues::processJeremy Morse2019-06-131-7/+13
| | | | | | | This was requested in D62904, which I successfully missed. This is just a refactor and shouldn't change any behaviour. llvm-svn: 363259
* [ARM] Set up infrastructure for MVE vector instructions.Simon Tatham2019-06-1312-94/+1306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit prepares the way to start adding the main collection of MVE instructions, which operate on the 128-bit vector registers. The most obvious thing that's needed, and the simplest, is to add the MQPR register class, which is like the existing QPR except that it has fewer registers in it. The more complicated part: MVE defines a system of vector predication, in which instructions operating on 128-bit vector registers can be constrained to operate on only a subset of the lanes, using a system of prefix instructions similar to the existing Thumb IT, in that you have one prefix instruction which designates up to 4 following instructions as subject to predication, and within that sequence, the predicate can be inverted by means of T/E suffixes ('Then' / 'Else'). To support instructions of this type, we've added two new Tablegen classes `vpred_n` and `vpred_r` for standard clusters of MC operands to add to a predicated instruction. Both include a flag indicating how the instruction is predicated at all (options are T, E and 'not predicated'), and an input register field for the register controlling the set of active lanes. They differ from each other in that `vpred_r` also includes an input operand for the previous value of the output register, for instructions that leave inactive lanes unchanged. `vpred_n` lacks that extra operand; it will be used for instructions that don't preserve inactive lanes in their output register (either because inactive lanes are zeroed, as the MVE load instructions do, or because the output register isn't a vector at all). This commit also adds the family of prefix instructions themselves (VPT / VPST), and all the machinery needed to work with them in assembly and disassembly (e.g. generating the 't' and 'e' mnemonic suffixes on disassembled instructions within a predicated block) I've added a couple of demo instructions that derive from the new Tablegen base classes and use those two operand clusters. The bulk of the vector instructions will come in followup commits small enough to be manageable. (One exception is that I've added the full version of `isMnemonicVPTPredicable` in the AsmParser, because it seemed pointless to carefully split it up.) Reviewers: dmgreen, samparker, SjoerdMeijer, t.p.northover Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62669 llvm-svn: 363258
* [CodeGen] Add getMachineMemOperand + MachineMemOperand::Flags allocator ↵Simon Pilgrim2019-06-132-8/+11
| | | | | | | | helper wrapper. NFCI. Pre-commit for D62726 on behalf of @luke (Luke Lau) llvm-svn: 363257
* [DebugInfo] Honour variable fragments in LiveDebugValuesJeremy Morse2019-06-131-39/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the LiveDebugValues pass consider fragments when propagating DBG_VALUE insts between blocks, fixing PR41979. Fragment info for a variable location is added to the open-ranges key, which allows distinct fragments to be tracked separately. To handle overlapping fragments things become slightly funkier. To avoid excessive searching for overlaps in the data-flow part of LiveDebugValues, this patch: * Pre-computes pairings of fragments that overlap, for each DILocalVariable * During data-flow, whenever something happens that causes an open range to be terminated (via erase), any fragments pre-determined to overlap are also terminated. The effect of which is that when encountering a DBG_VALUE fragment that overlaps others, the overlapped fragments do not get propagated to other blocks. We still rely on later location-list building to correctly handle overlapping fragments within blocks. It's unclear whether a mixture of DBG_VALUEs with and without fragmented expressions are legitimate. To avoid suprises, this patch interprets a DBG_VALUE with no fragment as overlapping any DBG_VALUE _with_ a fragment. Differential Revision: https://reviews.llvm.org/D62904 llvm-svn: 363256
* [AMDGPU][MC] Enabled constant expressions as operands of s_getreg/s_setregDmitry Preobrazhensky2019-06-135-107/+174
| | | | | | | | | | See bug 40820: https://bugs.llvm.org/show_bug.cgi?id=40820 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D61125 llvm-svn: 363255
* [ThinLTO][Bitcode] Add 'entrycount' to FS_COMBINED_PROFILE. NFCEugene Leviant2019-06-131-0/+1
| | | | | | Differential revision: https://reviews.llvm.org/D63078 llvm-svn: 363254
* [X86][SSE] Avoid assert for broadcast(horiz-op()) cases for non-f64 cases.Simon Pilgrim2019-06-131-6/+9
| | | | | | Based on fuzz test from @craig.topper llvm-svn: 363251
* [DebugInfo] Move Value struct out of DebugLocEntry as DbgValueLoc (NFC)Nikola Prica2019-06-133-106/+102
| | | | | | | | | | | | | Since the DebugLocEntry::Value is used as part of DwarfDebug and DebugLocEntry make it as the separate class. Reviewers: aprantl, dstenb Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D63213 llvm-svn: 363246
* [DebugInfo] Use FrameDestroy to extend stack locations to end-of-functionJeremy Morse2019-06-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | We aim to ignore changes in variable locations during the prologue and epilogue of functions, to avoid using space documenting location changes that aren't visible. However in D61940 / r362951 this got ripped out as the previous implementation was unsound. Instead, use the FrameDestroy flag to identify when we're in the epilogue of a function, and ignore variable location changes accordingly. This fits in with existing code that examines the FrameSetup flag. Some variable locations get shuffled in modified tests as they now cover greater ranges, which is what would be expected. Some additional single-location variables are generated too. Two tests are un-xfailed, they were only xfailed due to r362951 deleting functionality they depended on. Apparently some out-of-tree backends don't accurately maintain FrameDestroy flags -- if you're an out-of-tree maintainer and see changes in variable locations disappear due to a faulty FrameDestroy flag, it's safe to back this change out. The impact is just slightly more debug info than necessary. Differential Revision: https://reviews.llvm.org/D62314 llvm-svn: 363245
* [ARM] Refactor handling of IT mask operands.Simon Tatham2019-06-136-64/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During assembly, the mask operand to an IT instruction (storing the sequence of T/E for 'Then' and 'Else') is parsed out of the mnemonic into a representation that encodes 'Then' and 'Else' in the same way regardless of the condition code. At some point during encoding it has to be converted into the instruction encoding used in the architecture, in which the mask encodes a sequence of replacement low-order bits for the condition code, so that which bit value means 'then' and which 'else' depends on whether the original condition code had its low bit set. Previously, that transformation was done by processInstruction(), half way through assembly. So an MCOperand storing an IT mask would sometimes store it in one format, and sometimes in the other, depending on where in the assembly pipeline you were. You can see this in diagnostics from `llvm-mc -debug -triple=thumbv8a -show-inst`, for example: if you give it an instruction such as `itete eq`, you'd see an `<MCOperand Imm:5>` in a diagnostic become `<MCOperand Imm:11>` in the final output. Having the same data structure store values with time-dependent semantics is confusing already, and it will get more confusing when we introduce the MVE VPT instruction which reuses the Then/Else bitmask idea in a different context. So I'm refactoring: now, all `ARMOperand` and `MCOperand` representations of an IT mask work exactly the same way, namely, 0 means 'Then' and 1 means 'Else', regardless of what original predicate is being referred to. The architectural encoding of IT that depends on the original condition is now constructed at the point when we turn the `MCOperand` into the final instruction bit pattern, and decoded similarly in the disassembler. The previous condition-independent parse-time format used 0 for Else and 1 for Then. I've taken the opportunity to flip the sense of it while I'm changing all of this anyway, because it seems to me more natural to use 0 for 'leave the starting condition unchanged' and 1 for 'invert it', as if those bits were an XOR mask. Reviewers: ostannard Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63219 llvm-svn: 363244
* Improve reduction intrinsics by overloading result value.Sander de Smalen2019-06-132-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses the mechanism from D62995 to strengthen the definitions of the reduction intrinsics by letting the scalar result/accumulator type be overloaded from the vector element type. For example: ; The LLVM LangRef specifies that the scalar result must equal the ; vector element type, but this is not checked/enforced by LLVM. declare i32 @llvm.experimental.vector.reduce.or.i32.v4i32(<4 x i32> %a) This patch changes that into: declare i32 @llvm.experimental.vector.reduce.or.v4i32(<4 x i32> %a) Which has the type-constraint more explicit and causes LLVM to check the result type with the vector element type. Reviewers: RKSimon, arsenm, rnk, greened, aemerson Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62996 llvm-svn: 363240
* [NFC] Simplify Call querySam Parker2019-06-131-1/+1
| | | | | | Use getIntrinsicID() directly from IntrinsicInst. llvm-svn: 363235
* [ARM][TTI] Scan for existing loop intrinsicsSam Parker2019-06-131-5/+33
| | | | | | | | | TTI should report that it's not profitable to generate a hardware loop if it, or one of its child loops, has already been converted. Differential Revision: https://reviews.llvm.org/D63212 llvm-svn: 363234
* [IntrinsicEmitter] Extend argument overloading with forward references.Sander de Smalen2019-06-133-44/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the mechanism to overload intrinsic arguments by using either backward or forward references to the overloadable arguments. In for example: def int_something : Intrinsic<[LLVMPointerToElt<0>], [llvm_anyvector_ty], []>; LLVMPointerToElt<0> is a forward reference to the overloadable operand of type 'llvm_anyvector_ty' and would allow intrinsics such as: declare i32* @llvm.something.v4i32(<4 x i32>); declare i64* @llvm.something.v2i64(<2 x i64>); where the result pointer type is deduced from the element type of the first argument. If the returned pointer is not a pointer to the element type, LLVM will give an error: Intrinsic has incorrect return type! i64* (<4 x i32>)* @llvm.something.v4i32 Reviewers: RKSimon, arsenm, rnk, greened Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D62995 llvm-svn: 363233
* [SimplifyCFG] reverting preliminary Switch patches againShawn Landden2019-06-131-11/+13
| | | | | | | | | This reverts 363226 and 363227, both NFC intended I swear I fixed the test case that is failing, and ran the tests, but I will look into it again. llvm-svn: 363229
* [SimpligyCFG] NFC intended, remove GCD that was only used for powers of twoShawn Landden2019-06-131-13/+11
| | | | | | | | | | | | and replace with an equilivent countTrailingZeros. GCD is much more expensive than this, with repeated division. This depends on D60823 Differential Revision: https://reviews.llvm.org/D61151 llvm-svn: 363227
* X86: Clean up pass initializationTom Stellard2019-06-1314-43/+21
| | | | | | | | | | | | | | | | | | | | Summary: - Remove redundant initializations from pass constructors that were already being initialized by LLVMInitializeX86Target(). - Add initialization function for the FPS pass. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63218 llvm-svn: 363221
* Revert r361811: 'Re-commit r357452 (take 2): "SimplifyCFG ↵David L. Jones2019-06-131-15/+14
| | | | | | | | | | | | | | | | SinkCommonCodeFromPredecessors ...' We have observed some failures with internal builds with this revision. - Performance regressions: - llvm's SingleSource/Misc evalloop shows performance regressions (although these may be red herrings). - Benchmarks for Abseil's SwissTable. - Correctness: - Failures for particular libicu tests when building the Google AppEngine SDK (for PHP). hwennborg has already been notified, and is aware of reproducer failures. llvm-svn: 363220
* [IndVars] Extend diagnostic -replexitval flag w/ability to bypass hard use ↵Philip Reames2019-06-121-2/+5
| | | | | | | hueristic Note: This does mean that "always" is now more powerful than it was. llvm-svn: 363196
* [AMDGPU] gfx1010 dpp16 and dpp8Stanislav Mekhanoshin2019-06-1214-34/+585
| | | | | | Differential Revision: https://reviews.llvm.org/D63203 llvm-svn: 363186
* [AMDGPU] gfx1010 premlane instructionsStanislav Mekhanoshin2019-06-127-1/+142
| | | | | | Differential Revision: https://reviews.llvm.org/D63202 llvm-svn: 363185
* [Mips] Add s.d instruction alias for Mips1Simon Atanasyan2019-06-122-0/+58
| | | | | | | | | | | Add support for s.d instruction for Mips1 which expands into two swc1 instructions. Patch by Mirko Brkusanin. Differential Revision: https://reviews.llvm.org/D63199 llvm-svn: 363184
* [SCEV] Teach computeSCEVAtScope benefit from one-input Phi. PR39673Philip Reames2019-06-121-0/+10
| | | | | | | | | | | SCEV does not propagate arguments through one-input Phis so as to make it easy for the SCEV expander (and related code) to preserve LCSSA. It's not entirely clear this restriction is neccessary, but for the moment it exists. For this reason, we don't analyze single-entry phi inputs. However it is possible that when an this input leaves the loop through LCSSA Phi, it is a provable constant. Missing that results in an order of optimization issue in loop exit value rewriting where we miss some oppurtunities based on order in which we visit sibling loops. This patch teaches computeSCEVAtScope about this case. We can generalize it later, but so far we can only replace LCSSA Phis with their constant loop-exiting values. We should probably also add similiar logic directly in the SCEV construction path itself. Patch by: mkazantsev (with revised commit message by me) Differential Revision: https://reviews.llvm.org/D58113 llvm-svn: 363180
* [TargetLowering] Add MachineMemOperand::Flags to allowsMemoryAccess tests ↵Simon Pilgrim2019-06-1226-65/+77
| | | | | | | | | | | | | | (PR42123) As discussed on D62910, we need to check whether particular types of memory access are allowed, not just their alignment/address-space. This NFC patch adds a MachineMemOperand::Flags argument to allowsMemoryAccess and allowsMisalignedMemoryAccesses, and wires up calls to pass the relevant flags to them. If people are happy with this approach I can then update X86TargetLowering::allowsMisalignedMemoryAccesses to handle misaligned NT load/stores. Differential Revision: https://reviews.llvm.org/D63075 llvm-svn: 363179
* [X86][AVX] Fold concat(vpermilps(x,c),vpermilps(y,c)) -> ↵Simon Pilgrim2019-06-121-0/+30
| | | | | | | | | | vpermilps(concat(x,y),c) Handles PSHUFD/PSHUFLW/PSHUFHW (AVX2) + VPERMILPS (AVX1). An extra AVX1 PSHUFD->VPERMILPS combine will be added in a future commit. llvm-svn: 363178
* StackProtector: Use PointerMayBeCapturedMatt Arsenault2019-06-121-35/+4
| | | | | | | | | | | | | | | | This was using its own, outdated list of possible captures. This was at minimum not catching cmpxchg and addrspacecast captures. One change is now any volatile access is treated as capturing. The test coverage for this pass is quite inadequate, but this required removing volatile in the lifetime capture test. Also fixes some infrastructure issues to allow running just the IR pass. Fixes bug 42238. llvm-svn: 363169
* [ARM] Fix compiler warningMikael Holmen2019-06-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Without this fix clang 3.6 complains with: ../lib/Target/ARM/ARMAsmPrinter.cpp:1473:18: error: variable 'BranchTarget' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] } else if (MI->getOperand(1).isSymbol()) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../lib/Target/ARM/ARMAsmPrinter.cpp:1479:22: note: uninitialized use occurs here MCInst.addExpr(BranchTarget); ^~~~~~~~~~~~ ../lib/Target/ARM/ARMAsmPrinter.cpp:1473:14: note: remove the 'if' if its condition is always true } else if (MI->getOperand(1).isSymbol()) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../lib/Target/ARM/ARMAsmPrinter.cpp:1465:33: note: initialize the variable 'BranchTarget' to silence this warning const MCExpr *BranchTarget; ^ = nullptr 1 error generated. Discussed here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190610/661417.html llvm-svn: 363166
* LoopVersioning: Respect convergentMatt Arsenault2019-06-121-2/+3
| | | | | | | | | This changes the standalone pass only. Arguably the utility class itself should assert there are no convergent calls. However, a target pass with additional context may still be able to version a loop if all of the dynamic conditions are sufficiently uniform. llvm-svn: 363165
* [MIR] Skip hoisting to basic block which may throw exception or returnAnton Afanasyev2019-06-121-0/+2
| | | | | | | | | | | | | | | | Summary: Fix hoisting to basic block which are not legal for hoisting cause it can be terminated by exception or it is return block. Reviewers: john.brawn, RKSimon, MatzeB Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63148 llvm-svn: 363164
* LoopLoadElim: Respect convergentMatt Arsenault2019-06-121-0/+6
| | | | llvm-svn: 363162
* LoopDistribute/LAA: Respect convergentMatt Arsenault2019-06-122-10/+69
| | | | | | | | | | | | | | | | | | This case is slightly tricky, because loop distribution should be allowed in some cases, and not others. As long as runtime dependency checks don't need to be introduced, this should be OK. This is further complicated by the fact that LoopDistribute partially ignores if LAA says that vectorization is safe, and then does its own runtime pointer legality checks. Note this pass still does not handle noduplicate correctly, as this should always be forbidden with it. I'm not going to bother trying to fix it, as it would require more effort and I think noduplicate should be removed. https://reviews.llvm.org/D62607 llvm-svn: 363160
* Fix a Wunused-lambda-capture warning.Nico Weber2019-06-121-1/+1
| | | | | | | | The capture was added in the first commit of https://reviews.llvm.org/D61934 when it was used. In the reland, the use was removed but the capture wasn't removed. llvm-svn: 363155
* [ARM] Implement TTI::isHardwareLoopProfitableSam Parker2019-06-122-0/+200
| | | | | | | | | | | | | | | | | | | | Implement the backend target hook to drive the HardwareLoops pass. The low-overhead branch extension for Arm M-class cores is flexible enough that we don't have to ensure correctness at this point, except checking that the loop counter variable can be stored in LR - a 32-bit register. For it to be profitable, we want to avoid loops that contain function calls, or any other instruction that alters the PC. This implementation uses TargetLoweringInfo, to query type and operation actions, looks at intrinsic calls and also performs some manual checks for remainder/division and FP operations. I think this should be a good base to start and extra details can be filled out later. Differential Revision: https://reviews.llvm.org/D62907 llvm-svn: 363149
* [NFC][SCEV] Add NoWrapFlag argument to InsertBinOpSam Parker2019-06-121-19/+31
| | | | | | | | | | 'Use wrap flags in InsertBinop' (rL362687) was reverted due to miscompiles. This patch introduces the previous change to pass no-wrap flags but now only FlagAnyWrap is passed. Differential Revision: https://reviews.llvm.org/D61934 llvm-svn: 363147
* Share /machine: handling code with llvm-cvtres tooNico Weber2019-06-123-25/+46
| | | | | | | | | | | | | | r363016 let lld-link and llvm-lib share the /machine: parsing code. This lets llvm-cvtres share it as well. Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't need llvm-lib's dependencies on BinaryFormat and BitReader) and I couldn't find a good place to put this code. Since it's just a few lines, put it in lib/Object for now. Differential Revision: https://reviews.llvm.org/D63120 llvm-svn: 363144
* [XCore] CombineSTORE - Use allowsMemoryAccess wrapper. NFCI.Simon Pilgrim2019-06-121-9/+3
| | | | | | Noticed in D63075 - there was a allowsMisalignedMemoryAccesses call to check for unaligned loads and a check for aligned legal type loads - which is exactly what allowsMemoryAccess does. llvm-svn: 363141
* [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of ↵Ben Dunbobbin2019-06-121-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the IRSymtab Dependent libraries support for the legacy api was committed in a broken state (see: https://reviews.llvm.org/D60274). This was missed due to the painful nature of having to integrate the changes into a linker in order to test. This change implements support for dependent libraries in the legacy LTO api: - I have removed the current api function, which returns a single string, and added functions to access each dependent library specifier individually. - To reduce the testing pain, I have made the api functions as thin as possible to maximize coverage from llvm-lto. - When doing ThinLTO the system linker will load the modules lazily when scanning the input files. Unfortunately, when modules are lazily loaded there is no access to module level named metadata. To fix this I have added api functions that allow querying the IRSymtab for the dependent libraries. I hope to expand the api in the future so that, eventually, all the information needed by a client linker during scan can be retrieved from the IRSymtab. Differential Revision: https://reviews.llvm.org/D62935 llvm-svn: 363140
* [XCore] LowerLOAD/LowerSTORE - Use allowsMemoryAccess wrapper. NFCI.Simon Pilgrim2019-06-121-28/+14
| | | | | | Noticed in D63075 - there was a allowsMisalignedMemoryAccesses call to check for unaligned loads and a check for aligned legal type loads - which is exactly what allowsMemoryAccess does. llvm-svn: 363137
* Revert "[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step ↵Orlando Cazalet-Hyams2019-06-122-21/+7
| | | | | | | | | through loop even after completion" This reverts commit 1a0f7a2077b70c9864faa476e15b048686cf1ca7. See phabricator thread for D60831. llvm-svn: 363132
* [AArch64] Merge globals when optimising for sizeSjoerd Meijer2019-06-121-1/+14
| | | | | | | | | | | | | Extern global merging is good for code-size. There's definitely potential for performance too, but there's one regression in a benchmark that needs investigating, so that's why we enable it only when we optimise for size for now. Patch by Ramakota Reddy and Sjoerd Meijer. Differential Revision: https://reviews.llvm.org/D61947 llvm-svn: 363130
* [X86] Add VCMPSSZrr_Intk and VCMPSDZrr_Intk to isNonFoldablePartialRegisterLoad.Craig Topper2019-06-121-0/+2
| | | | | | | | | The non-masked versions are already in there. I'm having some trouble coming up with a way to test this right now. Most load folding should happen during isel so I'm not sure how to get peephole pass to do it. llvm-svn: 363125
* [RISCV] Add CFI directives for RISCV prologue/epilog.Hsiangkai Wang2019-06-123-4/+78
| | | | | | | | | In order to generate correct debug frame information, it needs to generate CFI information in prologue and epilog. Differential Revision: https://reviews.llvm.org/D61773 llvm-svn: 363120
* [NFC] Correct comments in RegisterCoalescer.Hsiangkai Wang2019-06-121-6/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D63124 llvm-svn: 363119
* Fix a bug in getSCEVAtScope w.r.t. non-canonical loopsPhilip Reames2019-06-111-2/+2
| | | | | | | | The issue is that if we have a loop with multiple predecessors outside the loop, the code was expecting to merge them and only return if equal, but instead returned the first one seen. I have no idea if this actually tripped anywhere. I noticed it by accident when reading the code and have no idea how to go about constructing a test case. llvm-svn: 363112
* Generalize icmp matching in IndVars' eliminateTruncPhilip Reames2019-06-111-14/+15
| | | | | | | | We were only matching RHS being a loop invariant value, not the inverse. Since there's nothing which appears to canonicalize loop invariant values to RHS, this means we missed cases. Differential Revision: https://reviews.llvm.org/D63112 llvm-svn: 363108
* [Analysis] add isSplatValue() for vectors in IRSanjay Patel2019-06-111-0/+39
| | | | | | | | | | | | | | We have the related getSplatValue() already in IR (see code just above the proposed addition). But sometimes we only need to know that the value is a splat rather than capture the splatted scalar value. Also, we have an isSplatValue() function already in SDAG. Motivation - recent bugs that would potentially benefit from improved splat analysis in IR: https://bugs.llvm.org/show_bug.cgi?id=37428 https://bugs.llvm.org/show_bug.cgi?id=42174 Differential Revision: https://reviews.llvm.org/D63138 llvm-svn: 363106
* [GlobalISel] Add a G_JUMP_TABLE opcode.Amara Emerson2019-06-112-0/+14
| | | | | | | | | | | | This opcode generates a pointer to the address of the jump table specified by the source operand, which is a jump table index. It will be used in conjunction with an upcoming G_BRJT opcode to support jump table codegen with GlobalISel. Differential Revision: https://reviews.llvm.org/D63111 llvm-svn: 363096
OpenPOWER on IntegriCloud