summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Silence "unused variable" warning in LiveIntervals.cpp after r335607Krzysztof Parzyszek2018-06-261-0/+1
| | | | llvm-svn: 335610
* Account for undef values from predecessors in extendSegmentsToUsesKrzysztof Parzyszek2018-06-263-16/+72
| | | | | | | | It is legal for a PHI node not to have a live value in a predecessor as long as the end of the predecessor is jointly dominated by an undef value. llvm-svn: 335607
* [TargetLowering] isVectorClearMaskLegal - use ArrayRef<int> instead of const ↵Simon Pilgrim2018-06-262-8/+6
| | | | | | | | | | SmallVectorImpl<int>& This is more generic and matches isShuffleMaskLegal. Differential Revision: https://reviews.llvm.org/D48591 llvm-svn: 335605
* [X86,ARM] Retain split-stack prolog check for sibling callsThan McIntosh2018-06-262-4/+8
| | | | | | | | | | | | | | | | | | | Summary: If a routine with no stack frame makes a sibling call, we need to preserve the stack space check even if the local stack frame is empty, since the call target could be a "no-split" function (in which case the linker needs to be able to fix up the prolog sequence in order to switch to a larger stack). This fixes PR37807. Reviewers: cherry, javed.absar Subscribers: srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D48444 llvm-svn: 335604
* Fix spelling mistakes in comments. NFCI.Simon Pilgrim2018-06-261-4/+4
| | | | llvm-svn: 335603
* [ThinLTO] Parse module summary index from assemblyTeresa Johnson2018-06-267-25/+1539
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
* [InstCombine] fold udiv with sext bool divisorSanjay Patel2018-06-261-1/+7
| | | | | | | | | | Note: I didn't add a hasOneUse() check because the existing, related fold doesn't have that check. I suspect that the improved analysis and codegen make these some of the rare canonicalization cases where we allow an increase in instructions. llvm-svn: 335597
* ARM: correctly decode VFP instructions following unpredictable t2ITTim Northover2018-06-261-0/+2
| | | | | | | | | When the condition code for an IT instruction is "AL" we get strange "15" predicates on subsequent instructions. These are dealt with for most instructions by treating them as "ARMCC::AL", but VFP takes a different path which didn't have this code. llvm-svn: 335594
* ARM: diagnose unpredictable IT instructionsTim Northover2018-06-262-1/+19
| | | | | | | | | | | IT instructions are allowed to have the 'AL' predicate, but it must never result in an 'NV' predicated instruction. Essentially this means that all branches must be 't' rather than 'e' if the predicate is 'AL'. This patch adds a diagnostic for this during assembly (error because parsing hits an assertion if allowed to continue) and an annotation during disassembly. llvm-svn: 335593
* [X86] Just use ArrayRef instead of SmallVectorImpl in a few static method ↵Simon Pilgrim2018-06-261-4/+4
| | | | | | arguments. NFCI. llvm-svn: 335590
* [IPSCCP] Change dead blocks to unreachable after visiting all executable blocks.Florian Hahn2018-06-261-3/+11
| | | | | | | | | | | | | | | | | changeToUnreachable may remove PHI nodes from executable blocks we found values for and we would fail to replace them. By changing dead blocks to unreachable after we replaced constants in all executable blocks, we ensure such PHI nodes are replaced by their known value before. Fixes PR37780. Reviewers: efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D48421 llvm-svn: 335588
* Fix MSVC "signed/unsigned mismatch" warning. NFCI.Simon Pilgrim2018-06-261-1/+1
| | | | llvm-svn: 335587
* Fix MSVC "not all control paths return a value" warnings. NFCI.Simon Pilgrim2018-06-261-0/+2
| | | | llvm-svn: 335584
* Improve ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-262-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to r334830 and r335031. In the valueCoversEntireFragment check we now also handle the situation when there is a variable length array (VLA) involved, and the length of the array has been reduced to a constant. The ConvertDebugDeclareToDebugValue functions that are related to PHI nodes and load instructions now avoid inserting dbg.value intrinsics when the value does not, for certain, cover the variable/fragment that should be described. In r334830 we assumed that the value always covered the entire var/fragment and we had assertions in the code to show that assumption. However, those asserts failed when compiling code with VLAs, so we removed the asserts in r335031. Now when we know that the valueCoversEntireFragment check can fail also for PHI/Load instructions we avoid to insert the faulty dbg.value intrinsic in such situations. Compared to the Store instruction scenario we simply drop the dbg.value here (as the variable does not change its value due to PHI/Load, so an earlier dbg.value describing the variable should still be valid). Reviewers: aprantl, vsk, efriedma Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48547 llvm-svn: 335580
* [InstCombine] (A + 1) + (B ^ -1) --> A - BGil Rapaport2018-06-261-0/+5
| | | | | | | | | Turn canonicalized subtraction back into (-1 - B) and combine it with (A + 1) into (A - B). This is similar to the folding already done for (B ^ -1) + Const into (-1 + Const) - B. Differential Revision: https://reviews.llvm.org/D48535 llvm-svn: 335579
* [X86] Don't use getScalarShiftAmountTy to get the immediate type for target ↵Craig Topper2018-06-261-5/+2
| | | | | | | | specific VSHLDQ/VSRLDQ nodes. These opcodes have a fixed type of i8 for their immediate and shouldn't have anything to do with the scalar shift amount used by target independent shift nodes. llvm-svn: 335578
* [WebAssembly] Fix lowering of varargs functions with non-legal fixed arguments.Dan Gohman2018-06-261-2/+3
| | | | | | | | | | | CallLoweringInfo's NumFixedArgs field gives the number of fixed arguments before legalization. The ISD::OutputArg "Outs" array holds legalized arguments, so when indexing into it to find the non-fixed arguemn, we need to use the number of arguments after legalization. Fixes PR37934. llvm-svn: 335576
* [X86] Use XOR for SUB (C, X) during isel if will help fold an immediateCraig Topper2018-06-261-0/+38
| | | | | | | | | | | | | | | | | Summary: Same idea as D48529, but restricted to X86 and done very late to avoid any surprises where subtract might be better for DAG combining. This seems like the safest way to do this trick. And we consider doing it as a DAG combine later. Reviewers: spatel, RKSimon Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48557 llvm-svn: 335575
* [WebAssembly] Fix a typo in a comment.Dan Gohman2018-06-261-1/+1
| | | | llvm-svn: 335574
* [ThinLTO] Add string saver onto index for value namesTeresa Johnson2018-06-262-5/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Adds a string saver to the ModuleSummaryIndex so it can store value names in the case of adding a ValueInfo for a GUID when we don't have the name stored in a Module string table. This is motivated by the upcoming summary parser patch, where we will read value names from the summary entry and want to store them, even when a Module is not available. Currently this allows us to store the name in the legacy bitcode case, and I have added a test to show that. Reviewers: pcc, dexonsmith Subscribers: mehdi_amini, inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47842 llvm-svn: 335570
* [X86] Redefine avx512 packed fpclass intrinsics to return a vXi1 mask and ↵Craig Topper2018-06-262-19/+49
| | | | | | | | | | | | implement the mask input argument using an 'and' IR instruction. This recommits r335562 and 335563 as a single commit. The frontend will surround the intrinsic with the appropriate marshalling to/from a scalar type to match the sigature of the builtin that software expects. By exposing the vXi1 type directly in the llvm intrinsic we make it available to optimizers much earlier. This can enable the scalar marshalling code to be optimized away. llvm-svn: 335568
* [ThinLTO] Add per-module indexes to combined index consistentlyTeresa Johnson2018-06-261-7/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: Without this change we only add module paths to the combined index when there is a module hash or at least one global value. Make this more consistent by adding the module to the index whenever there is a summary section, and it is a per-module summary (had a MODULE_CODE_SOURCE_FILENAME record). Since we will no longer add module paths lazily, add a new interface to get the module info from the index that asserts it is already added. Fixes PR37899. Reviewers: Vlad, pcc Subscribers: mehdi_amini, inglorion, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D48511 llvm-svn: 335567
* Revert r335562 and 335563 "[X86] Redefine avx512 packed fpclass intrinsics ↵Craig Topper2018-06-262-49/+19
| | | | | | | | to return a vXi1 mask and implement the mask input argument using an 'and' IR instruction." These were supposed to have been squashed to a single commit. llvm-svn: 335566
* [ORC] Add a symbolAliases function to the Core APIs.Lang Hames2018-06-261-9/+80
| | | | | | symbolAliases can be used to define symbol aliases within a VSO. llvm-svn: 335565
* fooCraig Topper2018-06-262-19/+49
| | | | llvm-svn: 335562
* [ThinLTO] Compute GUID directly from GV when building per-module indexTeresa Johnson2018-06-262-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: I discovered when writing the summary parsing support that the per-module index builder and writer are computing the GUID from the value name alone (ignoring the linkage type). This was ok since those GUID were not emitted in the bitcode, and there are never multiple conflicting names in a single module. However, I don't see a reason for making the GUID computation different for the per-module case. It also makes things simpler on the parsing side to have the GUID computation consistent. So this patch changes the summary analysis phase and the per-module summary writer to compute the GUID using the facility on the GlobalValue. Reviewers: pcc, dexonsmith Subscribers: llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D47844 llvm-svn: 335560
* Add a warning if someone attempts to add extra section flags to sectionsEric Christopher2018-06-251-16/+33
| | | | | | with well defined semantics like .rodata. llvm-svn: 335558
* [APInt] Add helpers for rounding u/sdivs.Tim Shen2018-06-251-0/+46
| | | | | | | | | | Reviewers: sanjoy, craig.topper Subscribers: jlebar, hiraditya, bixia, llvm-commits Differential Revision: https://reviews.llvm.org/D48498 llvm-svn: 335557
* [PM/LoopUnswitch] Teach the new unswitch to handle nontrivialChandler Carruth2018-06-251-156/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unswitching of switches. This works much like trivial unswitching of switches in that it reliably moves the switch out of the loop. Here we potentially clone the entire loop into each successor of the switch and re-point the cases at these clones. Due to the complexity of actually doing nontrivial unswitching, this patch doesn't create a dedicated routine for handling switches -- it would duplicate far too much code. Instead, it generalizes the existing routine to handle both branches and switches as it largely reduces to looping in a few places instead of doing something once. This actually improves the results in some cases with branches due to being much more careful about how dead regions of code are managed. With branches, because exactly one clone is created and there are exactly two edges considered, somewhat sloppy handling of the dead regions of code was sufficient in most cases. But with switches, there are much more complicated patterns of dead code and so I've had to move to a more robust model generally. We still do as much pruning of the dead code early as possible because that allows us to avoid even cloning the code. This also surfaced another problem with nontrivial unswitching before which is that we weren't as precise in reconstructing loops as we could have been. This seems to have been mostly harmless, but resulted in pointless LCSSA PHI nodes and other unnecessary cruft. With switches, we have to get this *right*, and everything benefits from it. While the testing may seem a bit light here because we only have two real cases with actual switches, they do a surprisingly good job of exercising numerous edge cases. Also, because we share the logic with branches, most of the changes in this patch are reasonably well covered by existing tests. The new unswitch now has all of the same fundamental power as the old one with the exception of the single unsound case of *partial* switch unswitching -- that really is just loop specialization and not unswitching at all. It doesn't fit into the canonicalization model in any way. We can add a loop specialization pass that runs late based on profile data if important test cases ever come up here. Differential Revision: https://reviews.llvm.org/D47683 llvm-svn: 335553
* [InstCombine] cleanup udiv folds; NFCISanjay Patel2018-06-251-30/+20
| | | | | | | | | This removes a "UDivFoldAction" in favor of a simple constant matcher. In theory, the existing code could do more matching, but I don't see any evidence or need for it. I've left a TODO about using ValueTracking in case we see any regressions. llvm-svn: 335545
* [Instrumentation] Remove unused includeBenjamin Kramer2018-06-251-1/+0
| | | | | | It's also a layering violation. llvm-svn: 335528
* [InstCombine] fold sdiv with sext bool divisorSanjay Patel2018-06-251-4/+7
| | | | llvm-svn: 335527
* Revert r335513: [SCEVExp] Advance found insertion pointFlorian Hahn2018-06-251-4/+3
| | | | llvm-svn: 335522
* [LoopIdiomRecognize] Fix a couple places where it appears we were ↵Craig Topper2018-06-251-6/+5
| | | | | | unintenionally making copies of DebugLoc. llvm-svn: 335521
* [X86] Simplify intrinsic table binary search to not require a temporary struct.Craig Topper2018-06-251-10/+9
| | | | | | std::lower_bound doesn't require the thing to search for to be the same type as the table entries. We just need to define an appropriate comparison function that can take an table entry and an intrinsic number. llvm-svn: 335518
* [X86] Add comment about the sorting of the memory folding tables added in ↵Craig Topper2018-06-251-0/+15
| | | | | | r335501. llvm-svn: 335517
* [PowerPC] Fix incorrectly encoded wait instructionLei Huang2018-06-251-1/+1
| | | | | | | | Encoding for the wait instruction was wrong. Fix according to ISA 3.0. Differential Revision: https://reviews.llvm.org/D48550 llvm-svn: 335514
* [SCEVExp] Advance found insertion point until we find a non-dbg instruction.Florian Hahn2018-06-251-3/+4
| | | | | | | | | | | | | This avoids creating unnecessary casts if the IP used to be a dbg info intrinsic. Fixes PR37727. Reviewers: vsk, aprantl, sanjoy, efriedma Reviewed By: vsk, efriedma Differential Revision: https://reviews.llvm.org/D47874 llvm-svn: 335513
* [InstSimplify] fold div/rem of zexted boolSanjay Patel2018-06-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was looking at an unrelated fold and noticed that we don't have this simplification (because the other fold would break existing tests). Name: zext udiv %z = zext i1 %x to i32 %r = udiv i32 %y, %z => %r = %y Name: zext urem %z = zext i1 %x to i32 %r = urem i32 %y, %z => %r = 0 Name: zext sdiv %z = zext i1 %x to i32 %r = sdiv i32 %y, %z => %r = %y Name: zext srem %z = zext i1 %x to i32 %r = srem i32 %y, %z => %r = 0 https://rise4fun.com/Alive/LZ9 llvm-svn: 335512
* Handle NetBSD specific path in findDebugBinary()Kamil Rytarowski2018-06-251-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: The NetBSD Operating System installs debuginfo files into /usr/libdata/debug, rather than other path like in some other popular distribution. This change makes llvm-symbolizer functional with the basesystem executables. Reviewers: joerg, vitalybuka Reviewed By: vitalybuka Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48525 llvm-svn: 335511
* Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code ↵Reid Kleckner2018-06-256-30/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | models" The large code model allows code and data segments to exceed 2GB, which means that some symbol references may require a displacement that cannot be encoded as a displacement from RIP. The large PIC model even relaxes the assumption that the GOT itself is within 2GB of all code. Therefore, we need a special code sequence to materialize it: .LtmpN: leaq .LtmpN(%rip), %rbx movabsq $_GLOBAL_OFFSET_TABLE_-.LtmpN, %rax # Scratch addq %rax, %rbx # GOT base reg From that, non-local references go through the GOT base register instead of being PC-relative loads. Local references typically use GOTOFF symbols, like this: movq extern_gv@GOT(%rbx), %rax movq local_gv@GOTOFF(%rbx), %rax All calls end up being indirect: movabsq $local_fn@GOTOFF, %rax addq %rbx, %rax callq *%rax The medium code model retains the assumption that the code segment is less than 2GB, so calls are once again direct, and the RIP-relative loads can be used to access the GOT. Materializing the GOT is easy: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx # GOT base reg DSO local data accesses will use it: movq local_gv@GOTOFF(%rbx), %rax Non-local data accesses will use RIP-relative addressing, which means we may not always need to materialize the GOT base: movq extern_gv@GOTPCREL(%rip), %rax Direct calls are basically the same as they are in the small code model: They use direct, PC-relative addressing, and the PLT is used for calls to non-local functions. This patch adds reasonably comprehensive testing of LEA, but there are lots of interesting folding opportunities that are unimplemented. I restricted the MCJIT/eh-lg-pic.ll test to Linux, since the large PIC code model is not implemented for MachO yet. Differential Revision: https://reviews.llvm.org/D47211 llvm-svn: 335508
* [X86] Sort the static memory folding tables by reg opcode. Remove the ↵Craig Topper2018-06-252-5419/+5328
| | | | | | | | | | | | reg->mem DenseMaps in favor of binary search. With the static tables sorted we can binary search them directly for reg->mem lookups. This removes 6 DenseMaps that had to be created when X86InstrInfo is constructed. We still have one Mem->Reg DenseMap for the reverse direction. This is created just as before by walking the reg->mem arrays to populate it. Differential Revision: https://reviews.llvm.org/D48527 llvm-svn: 335501
* [X86] Allow base and index for gather instructions to appear in other order ↵Craig Topper2018-06-251-0/+11
| | | | | | for Intel syntax. llvm-svn: 335500
* [SelectionDAG] Remove debug locations from ConstantSD(FP)NodesVedant Kumar2018-06-251-2/+2
| | | | | | | | | | | | | | | | | | This removes debug locations from ConstantSDNode and ConstantSDFPNode. When this kind of node is materialized we no longer create a line table entry which jumps back to the constant's first point of use. This makes single-stepping behavior smoother, and it matches the model used by IR, where Constants have no locations. See this thread for more context: http://lists.llvm.org/pipermail/llvm-dev/2018-June/124164.html I'd like to handle constant BuildVectorSDNodes and to try to eliminate passing SDLocs to SelectionDAG::getConstant*() in follow-up commits. Differential Revision: https://reviews.llvm.org/D48468 llvm-svn: 335497
* Add Triple::isMIPS()/isMIPS32()/isMIPS64(). NFCAlexander Richardson2018-06-2510-26/+13
| | | | | | | | | | | | | | There are quite a few if statements that enumerate all these cases. It gets even worse in our fork of LLVM where we also have a Triple::cheri (which is mips64 + CHERI instructions) and we had to update all if statements that check for Triple::mips64 to also handle Triple::cheri. This patch helps to reduce our diff to upstream and should also make some checks more readable. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48548 llvm-svn: 335493
* AMDGPU/GlobalISel: Add support for llvm.amdgcn.kernarg.segment.ptrMatt Arsenault2018-06-253-1/+29
| | | | | | | | | Note a normal select test is not currently possible because this relies on input registers tracked in SIMachineFunctionInfo which are not currently serializable in MIR, but this does work end-to-end from the IR. llvm-svn: 335490
* StackSlotColoring: Decide colors per stack IDMatt Arsenault2018-06-251-22/+50
| | | | | | | | | | | | | | | | I thought I fixed this in r308673, but that fix was very broken. The assumption that any frame index can be used in place of another was more widespread than I realized. Even when stack slot sharing was disabled, this was still replacing frame index uses with a different ID with a different stack slot. Really fix this by doing the coloring per-stack ID, so all of the coloring logically done in a separate namespace. This is a lot simpler than trying to figure out how to change the color if the stack ID is different. llvm-svn: 335488
* AMDGPU: Remove commented out codeMatt Arsenault2018-06-251-2/+0
| | | | llvm-svn: 335486
* AMDGPU/GlobalISel: Fix G_IMPLICIT_DEF for pointersMatt Arsenault2018-06-251-1/+5
| | | | llvm-svn: 335485
* [SampleFDO] Add an option to turn on/off warning about samples unused.Wei Mi2018-06-251-0/+8
| | | | | | | | | | | | | | | | | | If a function has sample to use, but cannot use them because of no debug information, currently a warning will be issued to inform the missing opportunity. This warning assumes the binary generating the profile and the binary using the profile are similar enough. It is not always the case. Sometimes even if the binaries are not quite similar, we may still get some benefit by using sampleFDO. In those cases, we may still want to apply sampleFDO but not want to see a lot of such warnings pop up. The patch adds an option for the warning. Differential Revision: https://reviews.llvm.org/D48510 llvm-svn: 335484
OpenPOWER on IntegriCloud