summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [test] Update the name of the debug entry values option. NFCDjordje Todorovic2019-09-061-1/+1
| | | | llvm-svn: 371199
* [DFAPacketizer] Track resources for packetized instructionsJames Molloy2019-09-065-60/+229
| | | | | | | | | | | | | | | | | | | | | | This patch allows the DFAPacketizer to be queried after a packet is formed to work out which resources were allocated to the packetized instructions. This is particularly important for targets that do their own bundle packing - it's not sufficient to know simply that instructions can share a packet; which slots are used is also required for encoding. This extends the emitter to emit a side-table containing resource usage diffs for each state transition. The packetizer maintains a set of all possible resource states in its current state. After packetization is complete, all remaining resource states are possible packetization strategies. The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default (most uses of the packetizer like MachinePipeliner don't care and don't need the extra maintained state). Differential Revision: https://reviews.llvm.org/D66936 llvm-svn: 371198
* Remove call to obsolete gethostbyname, using getaddrinfoSerge Guelton2019-09-061-4/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D67230 llvm-svn: 371195
* [clangd] Use override keyword to override the base class method, NFCHaojian Wu2019-09-061-3/+2
| | | | llvm-svn: 371194
* [DebugInfo] LiveDebugValues: explicitly terminate overwritten stack locationsJeremy Morse2019-09-062-12/+254
| | | | | | | | | | | | | | | | | | If a stack spill location is overwritten by another spill instruction, any variable locations pointing at that slot should be terminated. We cannot rely on spills always being restored to registers or variable locations being moved by a DBG_VALUE: the register allocator is entitled to spill a value and then forget about it when it goes out of liveness. To address this, scan for memory writes to spill locations, even those we don't consider to be normal "spills". isSpillInstruction and isLocationSpill distinguish the two now. After identifying spill overwrites, terminate the open range, and insert a $noreg DBG_VALUE for that variable. Differential Revision: https://reviews.llvm.org/D66941 llvm-svn: 371193
* [AMDGPU] Mark s_barrier as having side effects but not accessing memory.Jay Foad2019-09-067-68/+113
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes poor scheduling in a function containing a barrier and a few load instructions. Without this fix, ScheduleDAGInstrs::buildSchedGraph adds an artificial edge in the dependency graph from the barrier instruction to the exit node representing live-out latency, with a latency of about 500 cycles. Because of this it thinks the critical path through the graph also has a latency of about 500 cycles. And because of that it does not think that any of the load instructions are on the critical path, so it schedules them with no regard for their (80 cycle) latency, which gives poor results. Reviewers: arsenm, dstuttard, tpr, nhaehnle Subscribers: kzhuravl, jvesely, wdng, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67218 llvm-svn: 371192
* gn build: Merge r371182Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371191
* gn build: Merge r371179Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371190
* [ELF][test] Update test after r371185Fangrui Song2019-09-061-1/+1
| | | | llvm-svn: 371189
* [ARM] Fix for buildbotSam Parker2019-09-061-0/+3
| | | | llvm-svn: 371187
* [yaml2obj] Rename SHOffset (e_shoff) field to SHOff. NFCFangrui Song2019-09-066-12/+11
| | | | | | | | | | | `struct Elf*_Shdr` has a field `sh_offset`, named `ShOffset` in llvm::ELFYAML::Section. Rename SHOffset (e_shoff) to SHOff to prevent confusion. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D67254 llvm-svn: 371185
* Reland [LifetimeAnalysis] Support more STL idioms (template forward ↵Matthias Gehre2019-09-068-15/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declaration and DependentNameType) Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics. Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 371182
* [lldb][NFC] Remove Args::StripSpacesRaphael Isemann2019-09-064-61/+21
| | | | | | This just reimplemented llvm::StringRef::[r/l]trim(). llvm-svn: 371181
* [lldb][NFC] Extend ArgsTestRaphael Isemann2019-09-061-0/+68
| | | | llvm-svn: 371180
* [ARM] MVE Tail PredicationSam Parker2019-09-0612-1/+1985
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MVE and LOB extensions of Armv8.1m can be combined to enable 'tail predication' which removes the need for a scalar remainder loop after vectorization. Lane predication is performed implicitly via a system register. The effects of predication is described in Section B5.6.3 of the Armv8.1-m Arch Reference Manual, the key points being: - For vector operations that perform reduction across the vector and produce a scalar result, whether the value is accumulated or not. - For non-load instructions, the predicate flags determine if the destination register byte is updated with the new value or if the previous value is preserved. - For vector store instructions, whether the store occurs or not. - For vector load instructions, whether the value that is loaded or whether zeros are written to that element of the destination register. This patch implements a pass that takes a hardware loop, containing masked vector instructions, and converts it something that resembles an MVE tail predicated loop. Currently, if we had code generation, we'd generate a loop in which the VCTP would generate the predicate and VPST would then setup the value of VPR.PO. The loads and stores would be placed in VPT blocks so this is not tail predication, but normal VPT predication with the predicate based upon a element counting induction variable. Further work needs to be done to finally produce a true tail predicated loop. Because only the loads and stores are predicated, in both the LLVM IR and MIR level, we will restrict support to only lane-wise operations (no horizontal reductions). We will perform a final check on MIR during loop finalisation too. Another restriction, specific to MVE, is that all the vector instructions need operate on the same number of elements. This is because predication is performed at the byte level and this is set on entry to the loop, or by the VCTP instead. Differential Revision: https://reviews.llvm.org/D65884 llvm-svn: 371179
* [CodeGen] Do the Simple Early Return in block-placement pass to optimize the ↵Kang Zhang2019-09-062-8/+50
| | | | | | | | | | | | | | | | | | blocks Summary: Fix a bug of not update the jump table and recommit it again. In `block-placement` pass, it will create some patterns for unconditional we can do the simple early retrun. But the `early-ret` pass is before `block-placement`, we don't want to run it again. This patch is to do the simple early return to optimize the blocks at the last of `block-placement`. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D63972 llvm-svn: 371177
* [lldb][NFC] Remove unused Args::GetArgumentQuoteCharAtIndexRaphael Isemann2019-09-062-7/+0
| | | | llvm-svn: 371176
* [mips] Make another set of test cases more tolerant to exact symbol ↵Simon Atanasyan2019-09-0611-263/+178
| | | | | | addresses. NFC llvm-svn: 371174
* [CMake] LLVM_COMPILE_FLAGS also applies to C filesDavid Zarzycki2019-09-061-1/+1
| | | | | | | | | LLVM_COMPILE_FLAGS also applies to C files, otherwise tuning flags, etc. won't be picked up. https://reviews.llvm.org/D67171 llvm-svn: 371173
* [lldb] Remove xcode bot from website listing and fix link to sanitizedRaphael Isemann2019-09-061-2/+1
| | | | llvm-svn: 371172
* [MIR] Change test case to read from stdin instead of fileMikael Holmen2019-09-061-1/+1
| | | | | | | | | | | | | | | The ;CHECK: bb ;CHECK-NEXT: %namedVReg1353:_(p0) = COPY $d0 parts of the test case failed when the tests were placed in a directory including "bb" in the path, since the full path of the file is then output in the ; ModuleID = '/repo/bb/ line which the CHECK matched on and then the CHECK-NEXT failed. llvm-svn: 371171
* [X86] Add tests for extending and truncating between v16i8 and v16i64 with ↵Craig Topper2019-09-061-0/+67
| | | | | | | | | min-legal-vector-width=256. It looks like we might be able to do these in fewer steps, but I'm not sure. llvm-svn: 371170
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-065-6/+58
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* [X86] Pre-commit vector of __int128 test cases for D64672.Craig Topper2019-09-061-0/+49
| | | | llvm-svn: 371168
* [X86] Fix bad indentation. NFCCraig Topper2019-09-061-1/+1
| | | | llvm-svn: 371167
* [Windows] Add support of watchpoints to `ProcessWindows`Aleksandr Urakov2019-09-0627-158/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of watchpoints to the old `ProcessWindows` plugin. The `ProcessWindows` plugin uses the `RegisterContext` to set and reset watchpoints. The `RegisterContext` has some interface to access watchpoints, but it is very limited (e.g. it is impossible to retrieve the last triggered watchpoint with it), that's why I have implemented a slightly different interface in the `RegisterContextWindows`. Moreover, I have made the `ProcessWindows` plugin responsible for search of a vacant watchpoint slot, because watchpoints exist per-process (not per-thread), then we can place the same watchpoint in the same slot in different threads. With this scheme threads don't need to have their own watchpoint lists, and it simplifies identifying of the last triggered watchpoint. Reviewers: asmith, stella.stamenova, amccarth Reviewed By: amccarth Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67168 llvm-svn: 371166
* Fix rL371162 againAlex Brachet2019-09-061-4/+4
| | | | llvm-svn: 371164
* Fix failing test from rL371162Alex Brachet2019-09-061-2/+2
| | | | llvm-svn: 371163
* [yaml2obj] Make e_phoff and e_phentsize 0 if there are no program headersAlex Brachet2019-09-062-2/+17
| | | | | | | | | | | | | | | | Summary: It says [[ http://www.sco.com/developers/gabi/latest/ch4.eheader.html | here ]] that if there are no program headers than e_phoff should be 0, but currently it is always set after the header. GNU's `readelf` (but not `llvm-readelf`) complains about this: `readelf: Warning: possibly corrupt ELF header - it has a non-zero program header offset, but no program headers`. Reviewers: jhenderson, grimar, MaskRay, rupprecht Reviewed By: jhenderson, grimar, MaskRay Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67054 llvm-svn: 371162
* gn build: Merge r371159Nico Weber2019-09-061-0/+1
| | | | llvm-svn: 371161
* Update SHT_LLVM_PART_EHDR test after r371157Fangrui Song2019-09-061-2/+2
| | | | llvm-svn: 371160
* [MC] Fix undefined behavior in MCInstPrinter::formatHexJonas Devlieghere2019-09-063-12/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing INT64_MIN to MCInstPrinter::formatHex triggers undefined behavior because the negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long long'). This patch puts a workaround in place to just print the hex value directly. A possible alternative involves using a small helper functions that uses (implementation) defined conversions to achieve the desirable value: static int64_t helper(int64_t V) { auto U = static_cast<uint64_t>(V); return V < 0 ? -U : U; } The underlying problem is that MCInstPrinter::formatHex(int64_t) returns a format_object<int64_t> and should really return a format_object<uint64_t>. However, that's not possible because formatImm needs to be able to print both as decimal (where a signed is required) and hex (where we'd prefer to always have an unsigned). format_object<int64_t> formatImm(int64_t Value) const { return PrintImmHex ? formatHex(Value) : formatDec(Value); } Differential revision: https://reviews.llvm.org/D67236 llvm-svn: 371159
* Cleanup test.Alina Sbirlea2019-09-061-2/+1
| | | | llvm-svn: 371158
* [llvm-readobj][yaml2obj] Support SHT_LLVM_SYMPART, SHT_LLVM_PART_EHDR and ↵Fangrui Song2019-09-064-0/+31
| | | | | | | | | | | | | | | | | | | | | SHT_LLVM_PART_PHDR See http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html and D60242 for the lld partition feature. This patch: * Teaches yaml2obj to parse the 3 section types. * Teaches llvm-readobj/llvm-readelf to dump the 3 section types. There is no test for SHT_LLVM_DEPENDENT_LIBRARIES in llvm-readobj. Add it as well. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D67228 llvm-svn: 371157
* AMDGPU/GlobalISel: Avoid repeating 32-bit type listsMatt Arsenault2019-09-064-6/+14
| | | | llvm-svn: 371156
* AMDGPU/GlobalISel: Fix load/store of types in other address spacesMatt Arsenault2019-09-065-95/+116
| | | | | | There should probably be a size only matcher. llvm-svn: 371155
* GlobalISel/TableGen: Fix handling of EXTRACT_SUBREG constraintsMatt Arsenault2019-09-064-24/+78
| | | | | | | | | | | | | | | | This was only using the correct register constraints if this was the final result instruction. If the extract was a sub instruction of the result, it would attempt to use GIR_ConstrainSelectedInstOperands on a COPY, which won't work. Move the handling to createAndImportSubInstructionRenderer so it works correctly. I don't fully understand why runOnPattern and createAndImportSubInstructionRenderer both need to handle these special cases, and constrain them with slightly different methods. If I remove the runOnPattern handling, it does break the constraint when the final result instruction is EXTRACT_SUBREG. llvm-svn: 371150
* AMDGPU: Allow getMemOperandWithOffset to analyze stack accessesMatt Arsenault2019-09-056-43/+58
| | | | | | | Report soffset as a base register if the scratch resource can be ignored. llvm-svn: 371149
* AMDGPU: Fix emitting multiple stack loads for stack passed workitemsMatt Arsenault2019-09-052-12/+32
| | | | | | | | | | The same stack is loaded for each workitem ID, and each use. Nothing prevents you from creating multiple fixed stack objects with the same offsets, so this was creating a load for each unique frame index, despite them being the same offset. Re-use the same frame index so the loads are CSEable. llvm-svn: 371148
* [AArch64] Add testcase for codegen for sdiv by 2.Eli Friedman2019-09-051-0/+19
| | | | llvm-svn: 371147
* InstCombine: Fix crash on icmp of gep with addrspacecasted nullMatt Arsenault2019-09-052-2/+30
| | | | llvm-svn: 371146
* [Reproducer] Add a `cont` to ModuleCXX.testJonas Devlieghere2019-09-051-0/+1
| | | | | | | | | | On more than one occasion I've found this test got stuck during replay while waiting for a packet from debugserver when the debugger was in the process of being destroyed. For some reason it's more prevalent on the downstream Swift fork. Adding a cont mitigates the problem while I investigate. llvm-svn: 371144
* llvm-reduce: Use %python from lit to get the correct/valid python binary for ↵David Blaikie2019-09-053-4/+21
| | | | | | the reduction script llvm-svn: 371143
* AMDGPU: Fix Register copypaste errorMatt Arsenault2019-09-051-2/+2
| | | | llvm-svn: 371141
* [AliasSetTracker] Correct AAInfo check.Alina Sbirlea2019-09-052-2/+74
| | | | | | | | Properly check if NewAAInfo conflicts with AAInfo. Update local variable and alias set that a change occured when a conflict is found. Resolves PR42969. llvm-svn: 371139
* [SimplifyCFG] Don't SimplifyBranchOnICmpChain with ExtraCaseVitaly Buka2019-09-052-1/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Here we try to avoid issues with "explicit branch" with SimplifyBranchOnICmpChain which can check on undef. Msan by design reports branches on uninitialized memory and undefs, so we have false report here. In general msan does not like when we convert ``` // If at least one of them is true we can MSAN is ok if another is undefs if (a || b) return; ``` into ``` // If 'a' is undef MSAN will complain even if 'b' is true if (a) return; if (b) return; ``` Example Before optimization we had something like this: ``` while (true) { bool maybe_undef = doStuff(); while (true) { char c = getChar(); if (c != 10 && c != 13) continue break; } // we know that c == 10 || c == 13 if we get here, // so msan know that branch is not affected by maybe_undef if (maybe_undef || c == 10 || c == 13) continue; return; } ``` SimplifyBranchOnICmpChain will convert that into ``` while (true) { bool maybe_undef = doStuff(); while (true) { char c = getChar(); if (c != 10 && c != 13) continue; break; } // however msan will complain here: if (maybe_undef) continue; // we know that c == 10 || c == 13, so either way we will get continue switch(c) { case 10: continue; case 13: continue; } return; } ``` Reviewers: eugenis, efriedma Reviewed By: eugenis, efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67205 llvm-svn: 371138
* AMDGPU: Avoid constructing new std::vector in initCandidateMatt Arsenault2019-09-052-2/+5
| | | | | | | | | | | | Approximately 30% of the time was spent in the std::vector constructor. In one testcase this pushes the scheduler to being the second slowest pass. I'm not sure I understand why these vector are necessary. The default scheduler initCandidate seems to use some pre-existing vectors for the pressure. llvm-svn: 371136
* gn build: Merge r371134Nico Weber2019-09-051-0/+1
| | | | llvm-svn: 371135
* [Remarks] Add comparison operators to the Remark objectFrancis Visoiu Mistrih2019-09-053-0/+108
| | | | | | | | and related structs. This also adds tests for the remarks::Remark object in general. llvm-svn: 371134
* Remove `bugreport` commandJonas Devlieghere2019-09-055-156/+1
| | | | | | | | | | | | The bugreport command exists to create domain-specific bug reports. Currently it has one implementation for filing bugs on the unwinder. As far as we can tell, it has never been of use. Although not exactly the same as the reproducers, it's a bit confusing to have two parallel command trees for (kind of) the same thing. Differential revision: https://reviews.llvm.org/D65469 llvm-svn: 371132
OpenPOWER on IntegriCloud