summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [X86] Add test cases for D50952, paddus patterns involving constants. NFCCraig Topper2018-08-261-0/+2895
| | | | llvm-svn: 340694
* [ELF][HEXAGON] Add R_HEX_B13_PCREL relocation supportSid Manning2018-08-252-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D51166 llvm-svn: 340693
* [ELF][HEXAGON] Add R_HEX_B9_PCREL and R_HEX_B9_PCREL_X relocation supportSid Manning2018-08-252-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D51045 llvm-svn: 340692
* [C-API][DIBuilder] Use NameLen in LLVMDIBuilderCreateParameterVariableRobert Widmann2018-08-251-1/+1
| | | | | | | | | | | | | | Summary: NameLen wasn't being used and caused the parameters in gdb to very long, in my case, crashes in others. Please also perform the correct magical incarnations to have this be applied to the LLVM 7 branch. Reviewers: whitequark, CodaFi Reviewed By: CodaFi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51141 llvm-svn: 340691
* [X86] Replace support for vXi32 SMUL_LOHI/UMUL_LOHI with MULHS/MULHU support ↵Craig Topper2018-08-259-329/+259
| | | | | | | | | | | | | | | | | | | instead. Summary: The only time vector SMUL_LOHI/UMUL_LOHI nodes are created is during division/remainder lowering. If its created before op legalization, generic DAGCombine immediately turns that SMUL_LOHI/UMUL_LOHI into a MULHS/MULHU since only the upper half is used. That node will stick around through vector op legalization and will be turned back into UMUL_LOHI/SMUL_LOHI during op legalization. It will then be custom lowered by the X86 backend. Due to this two step lowering the vector shuffles created by the custom lowering get legalized after their inputs rather than before. This prevents the shuffles from being combined with any build_vector of constants. This patch uses changes vXi32 to use MULHS/MULHU instead. This is what the later DAG combine did anyway. But by skipping the change back to UMUL_LOHI/SMUL_LOHI we lower it before any constant BUILD_VECTORS. This allows the vector_shuffle creation to constant fold with the build_vectors. This accounts for the test changes here. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51254 llvm-svn: 340690
* [SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the ↵Craig Topper2018-08-259-59/+49
| | | | | | | | | | | | | | | | | | | | | value first. Summary: Previously the value being stored is the last operand in SDNode. This causes the type legalizer to visit the mask operand before the value operand. The type legalizer was more complicated because of this since we want the type of the value to drive the decisions. This patch moves the value to be the first operand so we visit it first during type legalization. It also simplifies the type legalization code accordingly. X86 is currently the only in tree target that uses this SDNode. Not sure if there are any users out of tree. Reviewers: RKSimon, delena, hfinkel, eli.friedman Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50402 llvm-svn: 340689
* [X86] Make sure type is a vector before calling VT.getVectorNumElements() in ↵Craig Topper2018-08-251-1/+1
| | | | | | | | combineLoopMAddPattern Fixes PR38700. llvm-svn: 340688
* Fix -Wunused-function warning. NFCI.Simon Pilgrim2018-08-251-9/+0
| | | | llvm-svn: 340687
* Remove superfluous semicolon. NFCI.Simon Pilgrim2018-08-251-1/+1
| | | | llvm-svn: 340686
* [x86] try harder to use broadcast to load a scalar into vector regSanjay Patel2018-08-257-111/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a preliminary step for a preliminary step for D50992. I noticed that x86 often misses chances to load a scalar directly into a vector register. So this patch is just allowing more of those cases to match a broadcast op in lowerBuildVectorAsBroadcast(). The old code comment said it doesn't make sense to use a broadcast when we're loading a single element and everything else is undef, but I think that's the best case in the improved tests in insert-loaded-scalar.ll. We avoid scalar-to-vector-register move and/or less efficient shuffling. Note that there are some existing types that were already producing a broadcast, but that happens semi-accidentally. Ie, it's not happening as part of lowerBuildVectorAsBroadcast(). The build vector gets expanded into load + shuffle, and then shuffle lowering produces the broadcast. Description of the other test diffs: 1. avx-basic.ll - replacing load+shufle is a win. 2. sse3-avx-addsub-2.ll - vmovddup vs. vbroadcastss is neutral 3. sse41.ll - don't care - we convert that intrinsic to generic IR now, so this test is deprecated 4. vector-shuffle-128-v8.ll / vector-shuffle-256-v16.ll - pshufb alternatives with an extra instruction are not obviously bad Differential Revision: https://reviews.llvm.org/D51125 llvm-svn: 340685
* [AMDGPU] Add support for multi-dword s.buffer.load intrinsicTim Renouf2018-08-2510-34/+389
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Patch by Marek Olsak and David Stuttard, both of AMD. This adds a new amdgcn intrinsic supporting s.buffer.load, in particular multiple dword variants. These are convenient to use from some front-end implementations. Also modified the existing llvm.SI.load.const intrinsic to common up the underlying implementation. This modification also requires that we can lower to non-uniform loads correctly by splitting larger dword variants into sizes supported by the non-uniform versions of the load. V2: Addressed minor review comments. V3: i1 glc is now i32 cachepolicy for consistency with buffer and tbuffer intrinsics, plus fixed formatting issue. V4: Added glc test. Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D51098 Change-Id: I83a6e00681158bb243591a94a51c7baa445f169b llvm-svn: 340684
* [InstCombine] add tests for shuffle+binop transform; NFCSanjay Patel2018-08-251-0/+52
| | | | llvm-svn: 340683
* [X86] Make requested test changes from D50636Simon Pilgrim2018-08-253-39/+74
| | | | | | The tests were relying on X / X -> 1 and X % X -> 0 combines not happening in the DAG. llvm-svn: 340682
* [CUDA/OpenMP] Define only some host macros during device compilationJonas Hahnfeld2018-08-253-8/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling CUDA or OpenMP device code Clang parses header files that expect certain predefined macros from the host architecture. To make this work the compiler passes the host triple via the -aux-triple argument and (until now) pulls in all macros for that "auxiliary triple" unconditionally. However this results in defines like __SSE_MATH__ that will trigger inline assembly making use of the "advertised" target features. See the discussion of D47849 and PR38464 for a detailed explanation of the encountered problems. Instead of blacklisting "known bad" examples this patch starts adding defines that are needed for certain headers like bits/wordsize.h and bits/mathinline.h. The disadvantage of this approach is that it decouples the definitions from their target toolchain. However in my opinion it's more important to keep definitions for one header close together. For one this will include a clear documentation why these particular defines are needed. Furthermore it simplifies maintenance because adding defines for a new header or support for a new aux-triple only needs to touch one piece of code. Differential Revision: https://reviews.llvm.org/D50845 llvm-svn: 340681
* [CodeGen] Set FrameSetup/FrameDestroy on BUNDLE instructionsBjorn Pettersson2018-08-252-3/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If any of the bundled instructions are marked as FrameSetup or FrameDestroy, then that property is set on the BUNDLE instruction as well. As long as the scheduler/packetizer aren't mixing prologue/epilogue instructions (i.e. all the bundled instructions have the same property) then this simply gives the bundle the correct property (so when using a bundle iterator in late passes a bundle will be correctly identified as FrameSetup/FrameDestroy). When for example bundling a mix of FrameSetup instructions with non-FrameSetup instructions it could be discussed if the bundle should have the property or not. The choice here has been to set these properties on the BUNDLE instruction if any of the bundled instructions have the property set. Reviewers: #debug-info, kparzysz Reviewed By: kparzysz Subscribers: vsk, thegameg, llvm-commits Differential Revision: https://reviews.llvm.org/D50637 llvm-svn: 340680
* [LiveDebugVariables] Avoid faulty addDefsFromCopies in computeIntervalsBjorn Pettersson2018-08-252-1/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When computeIntervals is looking through COPY instruction to extend the location mapping for a debug variable it did not handle subregisters correctly. For example DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 was transformed into DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 DBG_VALUE debug-use %1, ... So the subregister index was missing in the added DBG_VALUE. As long as the subreg refered to the least significant bits of the superreg, then I guess we could get the correct result in a debugger even when referring to the superreg. But as in the example above when the subreg refers to other parts of the superreg, then debuginfo would be incorrect. I'm not sure exactly how to fix this properly, so this patch just avoids looking through the COPY when there is a subreg involved (for more info, see the FIXME added in the code). Reviewers: rnk, aprantl Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D50788 llvm-svn: 340679
* [MC, RISCV] Fixed StringRef Assertion `Index < Length && "Invalid index!"'Ana Pazos2018-08-252-1/+4
| | | | | | | | | | | | | | | | | | Summary: Handle the case IDVal is an empty string. This bug was uncovered by a LLVM MC Assembler Protocol Buffer Fuzzer for the RISC-V assembly language. Reviewers: rnk Reviewed By: rnk Subscribers: rnk, niravd, pcc, peter.smith, asb, grosbach, llvm-commits, bcain, kito-cheng, shiva0217, rogfer01, PkmX Differential Revision: https://reviews.llvm.org/D50808 llvm-svn: 340678
* [llvm] Document "%T" as deprecated in CommandGuide/lit.rstKuba Mracek2018-08-251-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D48842 llvm-svn: 340677
* Disable exceptions for TestDataFormatterLibcxxOptional.pyFrederic Riss2018-08-251-1/+1
| | | | | | | | | | On macOS, some of the <optional> APIs used by the test are available only starting on macOS 10.14 when using exceptions. Build the test with -fno-exceptions so that the test builds on older systems too. rdar://problem/43700544 llvm-svn: 340676
* This patch adds support to LLVM for writing HermitCore ↵Eric Christopher2018-08-254-1/+12
| | | | | | | | | | | (https://hermitcore.org) ELF binaries. HermitCore is a POSIX-compatible kernel for running a single application in an isolated environment to get maximum performance and predictable runtime behavior. It can either be used bare-metal on hardware or a VM (Unikernel) or side by side to an existing Linux system (Multikernel). Due to the latter feature, HermitCore binaries are marked with ELFOSABI_STANDALONE to let the Linux ELF loader distinguish them from regular Unix/Linux binaries and load them using the HermitCore "proxy" tool. Patch by Colin Finck! llvm-svn: 340675
* [RISCV] Fixed Assertion`Kind == Immediate && "Invalid type access!"' failed.Ana Pazos2018-08-242-0/+35
| | | | | | | | | | | | | | | | | | Summary: Missing check for isImm() in some Immediate classes. This bug was uncovered by a LLVM MC Assembler Protocol Buffer Fuzzer for the RISC-V assembly language. Reviewers: hiraditya, asb Reviewed By: hiraditya, asb Subscribers: llvm-commits, hiraditya, kito-cheng, shiva0217, rkruppe, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei Differential Revision: https://reviews.llvm.org/D50797 llvm-svn: 340674
* Prevent DILocation::getMergedLocation() from creating invalid metadata.Adrian Prantl2018-08-242-0/+83
| | | | | | | | | | | | | | | | The function's new implementation from r340583 had a bug in it that could cause an invalid scope to be generated when merging two DILocations with no common ancestor scope. This patch detects this situation and picks the scope of the first location. This is not perfect, because the scope is misleading, but on the other hand, this will be a line 0 location. rdar://problem/43687474 Differential Revision: https://reviews.llvm.org/D51238 llvm-svn: 340672
* Port my recent changes from LLVM copy of the demangler:Richard Smith2018-08-241-24/+74
| | | | | | | | | | | r340663 - Allow Allocator::make to make a node of a different type than that requested. r340664 - Add documentation comment to ForwardTemplateReference. r340665 - Fix ExpandedSpecialSubstitution demangling for Sa and Sb. r340670 - Allow demangler's node allocator to fail, and bail out of the entire demangling process when it does. llvm-svn: 340671
* Allow demangler's node allocator to fail, and bail out of the entireRichard Smith2018-08-244-28/+109
| | | | | | | | | | | | | | | | demangling process when it does. Use this to support a "lookup" query for the mangling canonicalizer that does not create new nodes. This could also be used to implement demangling with a fixed-size temporary storage buffer. Reviewers: erik.pilkington Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51003 llvm-svn: 340670
* [RISCV] Fix std::advance slownessAna Pazos2018-08-241-2/+1
| | | | | | | | | | | | | | | | | | Summary: It seems std::advance template is treating "-MFI.getCalleeSavedInfo().size()" as a large unsigned value", causing slowness. Thanks to Henrik Gustafsson for reporting the issue. Reviewers: asb Reviewed By: asb Subscribers: llvm-commits, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, asb Differential Revision: https://reviews.llvm.org/D51148 llvm-svn: 340669
* [llvm-mca] Move ResourceManager from Scheduler into its own file. NFC.Matt Davis2018-08-245-621/+672
| | | | | | This time I should be preserving history of the ResourceManager changes. llvm-svn: 340668
* Revert r323281 "Adjust MaxAtomicInlineWidth for i386/i486 targets."Hans Wennborg2018-08-242-64/+5
| | | | | | | | | | | | | | | | | | | | | | | | As reported on http://lists.llvm.org/pipermail/cfe-dev/2018-August/058760.html, this broke i386-freebsd11 due to its lack of atomic 64 bit primitives. While that's not really this commit's fault, let's revert back to the old behaviour until this can be fixed. This means generating cmpxchg8b etc for i386 and i486 which don't technically support those, but that's been the behaviour for a long time, so a little longer probably doesn't hurt that much. > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > Differential Revision: https://reviews.llvm.org/D42154 llvm-svn: 340666
* Fix ExpandedSpecialSubstitution demangling for Sa and Sb.Richard Smith2018-08-241-2/+3
| | | | | | No functionality change: we never actually create these forms currently. llvm-svn: 340665
* Add documentation comment to ForwardTemplateReference.Richard Smith2018-08-241-0/+18
| | | | | | | This node doesn't directly correspond to a mangled name fragment, so it's useful to explicitly describe when it's created and what it's for. llvm-svn: 340664
* Add data structure to form equivalence classes of mangled names.Richard Smith2018-08-246-3/+717
| | | | | | | | | | | | | | | Summary: Given a set of equivalent name fragments, this mechanism determines whether two mangled names are equivalent. The intent is to use this for fuzzy matching of profile data against the program after certain refactorings are performed. Reviewers: erik.pilkington, dlj Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D50935 llvm-svn: 340663
* [llvm-mca] Revert r340659. NFC.Matt Davis2018-08-245-672/+621
| | | | | | | | Choosing to revert the change and do it again, hopefully preserving the history of the changes by using svn copy instead of simply creating a new file from the contents within Scheduler. llvm-svn: 340661
* [CVP] Extend tests to illustrate an old patch isn't neededPhilip Reames2018-08-241-0/+42
| | | | | | Back in https://reviews.llvm.org/D19559, I tried to teach CVP about range facts implied by value/value icmps (i.e. no constants.) In the meantime, we've implemented the optimization, but I couldn't find tests checked in, so adding them. llvm-svn: 340660
* [llvm-mca] Move the ResourceManger from the Scheduler into its own file. NFC.Matt Davis2018-08-245-621/+672
| | | | llvm-svn: 340659
* [vscode] Skip some of the vscode tests on Linux and fix oneStella Stamenova2018-08-243-0/+17
| | | | | | | | | | | | Summary: These are already skipped on Darwin because they cause build bot failures. Both on the build bots as well as in our testing we have seen a number of these tests fail and hang. This change skips the failing/hanging tests on Linux and also fixes one of the test - the test needs the thread library to build. Reviewers: asmith, clayborg, aprantl Subscribers: teemperor, lldb-commits Differential Revision: https://reviews.llvm.org/D51227 llvm-svn: 340658
* [PGO] add target md5sum in warning message for icallXinliang David Li2018-08-242-2/+3
| | | | | | Differential revision: http://reviews.llvm.org/D51193 llvm-svn: 340657
* [OpenMP] Remove deprecated/obsolete MIC attributes from headersJonathan Peyton2018-08-241-1/+3
| | | | llvm-svn: 340656
OpenPOWER on IntegriCloud