summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Disable use-color if the output stream is not a terminal with color support.Raphael Isemann2018-08-274-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: LLDB currently only checks the output terminal for color support by looking at the `TERM` environment variable and comparing it to `"dumb"`. This causes that when running LLDB on a CI node, the syntax highlighter will not be deactivated by LLDB and the output log is filled with color codes (unless the terminal emulator actually exposes itself as dumb). This patch now relies on the LLVM code for detecting color support which is more reliable. We now also correctly actually initialize the `m_supports_colors` variable in `File`. `m_supports_colors` was so far uninitialized, but the code path that uses `m_supports_colors` was also dead so the sanitizers didn't sound an alarm. The old check that compares `TERM` is not removed by this patch as the new LLVM code doesn't seem to handle this case (and it's a good thing to check for "dumb" terminals). Reviewers: aprantl, javed.absar Reviewed By: aprantl Subscribers: kristof.beyls, abidh, lldb-commits Differential Revision: https://reviews.llvm.org/D51243 llvm-svn: 340747
* [llvm-mca] Improved report generated by the SchedulerStatistics view.Andrea Di Biagio2018-08-279-109/+231
| | | | | | | | | | | | | Before this patch, the SchedulerStatistics only printed the maximum number of buffer entries consumed in each scheduler's queue at a given point of the simulation. This patch restructures the reported table, and adds an extra field named "Average number of used buffer entries" to it. This patch also uses different colors to help identifying bottlenecks caused by high scheduler's buffer pressure. llvm-svn: 340746
* [OpenMP][Fix] Ensure comparison between unsigned values.Gheorghe-Teodor Bercea2018-08-271-1/+1
| | | | | | | | | | | | | | Summary: Ensure the values being compared are both unsigned. Reviewers: ABataev, Hahnfeld, caomhin, grokos, AndreyChurbanov Reviewed By: AndreyChurbanov Subscribers: AndreyChurbanov, guansong, openmp-commits Differential Revision: https://reviews.llvm.org/D51301 llvm-svn: 340745
* fix comment typoNico Weber2018-08-273-3/+3
| | | | llvm-svn: 340744
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340743
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340742
* [SelectionDAG] add helper query for binops; NFCSanjay Patel2018-08-272-11/+14
| | | | | | We will also use this in a planned enhancement for vector insertelement. llvm-svn: 340741
* [PowerPC] Revert commit r339779Nemanja Ivanovic2018-08-276-109/+23
| | | | | | | This commit has caused failures in some internal benchmarks. Temporarily reverting this patch until the issue can be diagnosed and fixed. llvm-svn: 340740
* [ELF][HEXAGON] Add R_HEX_11/10/9_X supportSid Manning2018-08-272-0/+30
| | | | | | Differential Revision: https://reviews.llvm.org/D51225 llvm-svn: 340739
* Handle identifying AMDGPU bitcode filesMatt Arsenault2018-08-273-0/+27
| | | | llvm-svn: 340738
* [X86] Adding the test pointing to the fail case of D45653Aleksandr Urakov2018-08-271-0/+29
| | | | | | | | Summary: This commit adds the case of tail calling a sret function from a non-sret function when both functions have the C calling convention. llvm-svn: 340737
* [Sparc] Avoid writing outside array in applyFixupDaniel Cederman2018-08-272-3/+23
| | | | | | | | | | | | | | | | Summary: If an object file ends with a relocation that is smaller than 4 bytes we will write outside the Data array and trigger an "Invalid index" assertion. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D50971 llvm-svn: 340736
* [NFC][X86] Fix `sibcall.ll` formattingAleksandr Urakov2018-08-271-317/+303
| | | | | | | | Summary: Remove unnecessary lines from `sibcall.ll` and rename labels according to @RKSimon's recommendations in the D45653 conversation. llvm-svn: 340735
* [PowerPC] Recommit r340016 after fixing the reported issueNemanja Ivanovic2018-08-275-3/+55
| | | | | | | | The internal benchmark failure reported by Google was due to a missing check for the result type for the sign-extend and shift DAG. This commit adds the check and re-commits the patch. llvm-svn: 340734
* [Sparc] Add support for the cycle counter available in GR740Daniel Cederman2018-08-277-2/+36
| | | | | | | | | | | | | | | | | Summary: The GR740 provides an up cycle counter in the registers ASR22 and ASR23. As these registers can not be read together atomically we only use the value of ASR23 for llvm.readcyclecounter(). The ASR23 register holds the 32 LSBs of the up-counter. Reviewers: jyknight, venkatra Reviewed By: jyknight Subscribers: jfb, fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D48638 llvm-svn: 340733
* [NFC] Try to make buildbot happy about virtual destructorsMax Kazantsev2018-08-271-0/+2
| | | | llvm-svn: 340732
* [clangd] Use TRUE iterator instead of complete posting listKirill Bobyrev2018-08-271-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stop using `$$$` (empty) trigram and generating a posting list with all items. Since TRUE iterator is already implemented and correctly inserted when there are no real trigram posting lists, this is a valid transformation. Benchmarks show that this simple change allows ~30% speedup on dataset of real completion queries. Before ``` ------------------------------------------------------- Benchmark Time CPU Iterations ------------------------------------------------------- DexAdHocQueries 5640321 ns 5640265 ns 120 DexRealQ 939835603 ns 939830296 ns 1 ``` After ``` ------------------------------------------------------- Benchmark Time CPU Iterations ------------------------------------------------------- DexAdHocQueries 3452014 ns 3451987 ns 203 DexRealQ 667455912 ns 667455750 ns 1 ``` Reviewed by: ilya-biryukov Differential Revision: https://reviews.llvm.org/D51287 llvm-svn: 340729
* [NFC] Split logic of ImplicitControlFlowTracking to allow generalizationMax Kazantsev2018-08-276-157/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | We have a class `ImplicitControlFlowTracking` which allows us to keep track of instructions that can abnormally exit and answer queries like "whether or not there is side-exiting instruction above this instruction in its block". We may want to have the similar tracking for other types of "special" instructions, for example instructions that write memory. This patch separates ImplicitControlFlowTracking into two classes, isolating all general logic not related to implicit control flow into its parent class. We can later make another child of this class to keep track of instructions that write memory. The motivation for that is that we want to make these checks efficiently in the patch https://reviews.llvm.org/D50891. NOTE: The naming of the parent class is not super cool, but the other options we have are hardly better. Please feel free to rename it as NFC if you think you've found a more informative name for it. Differential Revision: https://reviews.llvm.org/D50954 Reviewed By: fedor.sergeev llvm-svn: 340728
* Try to fix this clang driver test case after r340709.Chandler Carruth2018-08-271-2/+2
| | | | | | | | If any of the bots complain about this, I'll just revert. This test case is essentially trying to test the exact change made, but I think this matches the intent of the patch in question. llvm-svn: 340727
* [COFF] Support MinGW automatic dllimport of dataMartin Storsjo2018-08-2714-0/+495
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
* [COFF] Expose an easier helper function for getting names for relocation typesMartin Storsjo2018-08-272-16/+19
| | | | | | | | | The existing method is protected, and requires using DataRefImpl and SmallVector. Differential Revision: https://reviews.llvm.org/D50995 llvm-svn: 340725
* [Sparc] Custom bitcast between f64 and v2i32Daniel Cederman2018-08-273-15/+64
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently bitcasting constants from f64 to v2i32 is done by storing the value to the stack and then loading it again. This is not necessary, but seems to happen because v2i32 is a valid type for Sparc V8. If it had not been legal, we would have gotten help from the type legalizer. This patch tries to do the same work as the legalizer would have done by bitcasting the floating point constant and splitting the value up into a vector of two i32 values. Reviewers: venkatra, jyknight Reviewed By: jyknight Subscribers: glaubitz, fedor.sergeev, jrtc27, llvm-commits Differential Revision: https://reviews.llvm.org/D49219 llvm-svn: 340723
* [RISCV] atomic_store_nn have a different layout to regular storeRoger Ferrer Ibanez2018-08-272-16/+27
| | | | | | | | | | | We cannot directy reuse the patterns of StPat because for some reason the store DAG node and the atomic_store_nn DAG nodes put the ptr and the value in different positions. Currently we attempt to store the address to an address formed by the value. Differential Revision: https://reviews.llvm.org/D51217 llvm-svn: 340722
* Fix this file to have the necessary standard library includes and useChandler Carruth2018-08-271-2/+2
| | | | | | the `std::` namespace. Should fix a number of build bots as well. llvm-svn: 340721
* [X86] Cleanup the LowerMULH code by hoisting some commonalities between the ↵Craig Topper2018-08-271-24/+20
| | | | | | | | | | vXi32 and vXi8 handling. NFCI vXi32 support was recently moved from LowerMUL_LOHI to LowerMULH. This commit shares the getOperand calls, switches both to use common IsSigned flag, and hoists the NumElems/NumElts variable. llvm-svn: 340720
* [X86] Add intrinsics for kand/kandn/knot/kor/kxnor/kxor with 8, 32, and ↵Craig Topper2018-08-278-12/+427
| | | | | | | | | | 64-bit mask registers. This also adds a second intrinsic name for the 16-bit mask versions. These intrinsics match gcc and icc. They just aren't published in the Intel Intrinsics Guide so I only recently found they existed. llvm-svn: 340719
* [X86] Remove min_vector_width 512 from some intrinsics that operate only on ↵Craig Topper2018-08-271-0/+2
| | | | | | k-registers. llvm-svn: 340718
* [X86] Rename __DEFAULT_FN_ATTRS to a__DEFAULT_FN_ATTRS512 in ↵Craig Topper2018-08-272-297/+295
| | | | | | | | avx512dqintrin.h and avx512bwintrin.h. This is preparation for adding removing min_vector_width 512 from some intrinsics. llvm-svn: 340717
* Rename a function to follow the LLVM coding style.Rui Ueyama2018-08-276-6/+6
| | | | llvm-svn: 340716
* [COFF] Check the instructions in ARM MOV32T relocationsMartin Storsjo2018-08-272-3/+101
| | | | | | | | | | For this relocation, which applies to two consecutive instructions, it's plausible that the second instruction might not actually be the right one. Differential Revision: https://reviews.llvm.org/D50998 llvm-svn: 340715
* [X86] Undef __DEFAULT_FN_ATTRS in avx512fintrin.h.Craig Topper2018-08-271-0/+1
| | | | | | Fixes test failure after r340713 llvm-svn: 340714
* [X86] Don't set min_vector_width to 512 on intrinsics that only operate on k ↵Craig Topper2018-08-271-12/+13
| | | | | | registers. llvm-svn: 340713
* [Xray] Darwin - Enable in the driver sideDavid Carlier2018-08-275-3/+12
| | | | | | | | | | Reviewers: dberris Reviered By: dberris Differential Revision: https://reviews.llvm.org/D51269 llvm-svn: 340712
* [MS Demangler] Add virtual destructor.Zachary Turner2018-08-271-0/+1
| | | | | | Silence -Wnon-virtual-dtor. llvm-svn: 340711
* [MS Demangler] Re-write the Microsoft demangler.Zachary Turner2018-08-278-1839/+2192
| | | | | | | | | | | | | | | | | | | | This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
* [Driver] Change MipsLinux default linker from "lld" to "ld.lld"Fangrui Song2018-08-261-1/+1
| | | | | | | | | | | | Reviewers: kzhuravl, atanasyan Reviewed By: atanasyan Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits Differential Revision: https://reviews.llvm.org/D51234 llvm-svn: 340709
* [X86] Correct the cost of (v4i32 (fptoui (v4f64))) under AVX512F.Craig Topper2018-08-262-2/+3
| | | | | | | | | | | | | | Summary: This was inheriting the cost from the AVX table, but should be legal under AVX512. Reviewers: RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51267 llvm-svn: 340708
* [X86] Add FeatureCMOV explicitly to all CPUs that support it. Remove ↵Craig Topper2018-08-264-20/+37
| | | | | | | | | | | | | | | | | | | | | | | | | FeatureCMOV implication from Feature64Bit and FeatureSSE1 Summary: Previously most CPUs inherited cmov support through Feature64Bit(or FeatureCMPXCHG16HB implying Feature64Bit) or FeatureSSE1. This has the surprising side effect that -mattr=-cmov causes an assert to fire in 64-bit mode because it clears the Feature64Bit. Or in 32-bit mode, -mattr=-cmov disables any sse/avx features which seems surprising. This patch removes the implication and instead updates hasCMOV in X86Subtarget to check SSE1 or is64Bit in addition to the regular cmov flag. This should keep most things working the way they did before. I don't believe there is a way to specific "-cmov" directly from clang so this should only effect our lower level tools. This does stop -mattr=cx16(cmpxchg16b) from implying cmov is enabled via the 64bit flag as you can see from one of the changed tests. But that was a 32-bit test so I don't know why it enabled cx16 anyway. For the other test I had to add -sse to override the new sse check in hasCMOV. Reviewers: RKSimon, DavidKreitzer, spatel Reviewed By: RKSimon Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D51228 llvm-svn: 340707
* [X86] Add FeatureCMOV to athlon and athlon-tbird cpus.Craig Topper2018-08-262-1/+322
| | | | | | | | | | | | | | Summary: This matches gcc and one cpuid dump I found online. Given that these are considered 7th generation x86 CPU it seems likely they support cmov since cmov was added by Intel in their 6th generation. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51264 llvm-svn: 340706
* [SelectionDAG][x86] turn insertelement into undef with variable index into splatSanjay Patel2018-08-265-283/+242
| | | | | | | | | | | | | | | | | | I noticed this along with the patterns in D51125, but when the index is variable, we don't convert insertelement into a build_vector. For x86, that means these get expanded at legalization time into the loading/spilling code that we see in the tests. I think it's always better to avoid going to memory on these, and we get the optimal 'broadcast' if it's available. I suspect other targets may want to look at enabling the hook. AArch64 and AMDGPU have regression tests that would be affected (although I did not check what would happen in those cases). In the most basic cases shown here, AArch64 would probably do much better with a splat. Differential Revision: https://reviews.llvm.org/D51186 llvm-svn: 340705
* [ORC] Remove a workaround for systems lacking 8-byte atomics.Lang Hames2018-08-261-5/+0
| | | | | | | SymbolStringPool ref counts are now size_t, rather than uint64_t, so I do not think this is necessary any more. llvm-svn: 340704
* [ORC] Do not include non-global symbols in getObjectSymbolFlags.Lang Hames2018-08-261-11/+16
| | | | | | | | | | | Private symbols are not visible outside the object file, and so not defined by the object file from ORC's perspective. No test case yet. Ideally this would be a unit test parsing a checked-in binary, but I am not aware of any way to reference the LLVM source root from a unit test. llvm-svn: 340703
* Replace fancy use of initializer lists with simple functions that returnChandler Carruth2018-08-261-194/+208
| | | | | | | | | | vectors, and move this test code into an anonymous namespace. Hoping that this will avoid hitting an MSVC bug that causes it to crash and burn pretty spectacularly. Also, this degree of clever use of initializer lists seems somewhat questionable in general. ;] llvm-svn: 340702
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-2639-57/+64
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* Avoid specializing a variadic member template in a way that seems to notChandler Carruth2018-08-261-15/+13
| | | | | | | | | agree with MSVC. There isn't actually a need for specialization here as we can write the code generically and just have a test that will fold away as a constant. llvm-svn: 340700
* [IR] Sink `isExceptional` predicate to `Instruction`, rename it toChandler Carruth2018-08-2610-22/+25
| | | | | | | | | | | `isExceptionalTermiantor` and implement it for opcodes as well following the common pattern in `Instruction`. Part of removing `TerminatorInst` from the `Instruction` type hierarchy to make it easier to share logic and interfaces between instructions that are both terminators and not terminators. llvm-svn: 340699
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-2618-259/+282
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [MIPS GlobalISel] Legalize i8 and i16 addPetar Jovanovic2018-08-263-4/+264
| | | | | | | | | | | | Legalize G_ADD for types smaller than i32. LegalizationArtifactCombiner replaces extend instructions with appropriate bitwise instructions. Patch by Petar Avramovic. Differential Revision: https://reviews.llvm.org/D51213 llvm-svn: 340697
* [index] Introduce 'ProtocolInterface' as part of SymbolPropertySetArgyrios Kyrtzidis2018-08-264-5/+12
| | | | | | | This is useful to directly infer that a method or property is from a protocol interface at the point of the symbol occurrences. llvm-svn: 340696
* [X86] Fix typo in comment, expect->except. NFCCraig Topper2018-08-261-1/+1
| | | | llvm-svn: 340695
OpenPOWER on IntegriCloud