summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [MC] Plumb unique_ptr<MCELFObjectTargetWriter> through createELFObjectWriter toLang Hames2017-10-0912-33/+33
| | | | | | | | | | ELFObjectWriter's constructor. Fixes the same ownership issue for ELF that r315245 did for MachO: ELFObjectWriter takes ownership of its MCELFObjectTargetWriter, so we want to pass this through to the constructor via a unique_ptr, rather than a raw ptr. llvm-svn: 315254
* Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet2017-10-0929-30/+30
| | | | | | | Sync it up with the name of the class actually defined here. This has been bothering me for a while... llvm-svn: 315249
* [MC] Plumb unique_ptr<MCMachObjectTargetWriter> through createMachObjectWriterLang Hames2017-10-095-14/+12
| | | | | | | | | | | to MCObjectWriter's constructor. MCObjectWriter takes ownership of its MCMachObjectTargetWriter argument -- this patch plumbs that ownership relationship through the constructor (which previously took raw MCMachObjectTargetWriter*) and the createMachObjectWriter function. llvm-svn: 315245
* [GISel]: Fix generation of illegal COPYs during CallLoweringAditya Nandakumar2017-10-094-16/+58
| | | | | | | | | | | We end up creating COPY's that are either truncating/extending and this should be illegal. https://reviews.llvm.org/D37640 Patch for X86 and ARM by igorb, rovka llvm-svn: 315240
* [X86] Unsigned saturation subtraction canonicalization [the backend part]Zvi Rackover2017-10-091-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On behalf of julia.koval@intel.com The patch transforms canonical version of unsigned saturation, which is sub(max(a,b),a) or sub(a,min(a,b)) to special psubus insturuction on targets, which support it(8bit and 16bit uints). umax(a,b) - b -> subus(a,b) a - umin(a,b) -> subus(a,b) There is also extra case handled, when right part of sub is 32 bit and can be truncated, using UMIN(this transformation was discussed in https://reviews.llvm.org/D25987). The example of special case code: ``` void foo(unsigned short *p, int max, int n) { int i; unsigned m; for (i = 0; i < n; i++) { m = *--p; *p = (unsigned short)(m >= max ? m-max : 0); } } ``` Max in this example is truncated to max_short value, if it is greater than m, or just truncated to 16 bit, if it is not. It is vaid transformation, because if max > max_short, result of the expression will be zero. Here is the table of types, I try to support, special case items are bold: | Size | 128 | 256 | 512 | ----- | ----- | ----- | ----- | i8 | v16i8 | v32i8 | v64i8 | i16 | v8i16 | v16i16 | v32i16 | i32 | | **v8i32** | **v16i32** | i64 | | | **v8i64** Reviewers: zvi, spatel, DavidKreitzer, RKSimon Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37534 llvm-svn: 315237
* [MC] Use a unique_ptr<MCAssembler> for MCObjectStreamer's Assembler member.Lang Hames2017-10-091-3/+2
| | | | | | Removes manual new/delete. llvm-svn: 315225
* [InstCombine] fix formatting; NFCSanjay Patel2017-10-091-9/+7
| | | | llvm-svn: 315223
* Fix after r315079Adrian McCarthy2017-10-091-1/+1
| | | | | | | | | | | | Microsoft's debug implementation of std::copy checks if the destination is an array and then does some bounds checking. This was causing an assertion failure in fs::rename_internal which copies to a buffer of the appropriate size but that's type-punned to an array of length 1 for API compatibility reasons. Fix is to make make the destination a pointer rather than an array. llvm-svn: 315222
* [DAG] combine assertsexts around a truncSanjay Patel2017-10-091-10/+10
| | | | | | | This was a suggested follow-up to: D37017 / https://reviews.llvm.org/rL313577 llvm-svn: 315206
* [AArch64] Improve codegen for inverted overflow checking intrinsicsAmara Emerson2017-10-091-9/+33
| | | | | | | | | | | | | | E.g. if we have a (xor(overflow-bit), 1) where overflow-bit comes from an intrinsic like llvm.sadd.with.overflow then we can kill the xor and use the inverted condition code for the CSEL. rdar://28495949 Reviewed By: kristof.beyls Differential Revision: https://reviews.llvm.org/D38160 llvm-svn: 315205
* [X86] Remove a setLoadExtAction from the AVX512 section that uses an ↵Craig Topper2017-10-091-1/+0
| | | | | | AVX512BW type and is alraedy present in the AVX512BW section. llvm-svn: 315202
* [X86] Enable extended comparison predicate support for SETUEQ/SETONE when ↵Craig Topper2017-10-092-18/+16
| | | | | | | | | | targeting AVX instructions. We believe that despite AMD's documentation, that they really do support all 32 comparision predicates under AVX. Differential Revision: https://reviews.llvm.org/D38609 llvm-svn: 315201
* [X86][SSE] Don't call combineTo inside combineX86ShufflesRecursively. NFCI.Simon Pilgrim2017-10-081-51/+60
| | | | | | | | Return the combined shuffle from combineX86ShufflesRecursively and perform the combineTo in the caller. Makes it easier for future patches to use this in functions that aren't actually shuffles themselves. llvm-svn: 315195
* Tidyup with clang-format. NFCI.Simon Pilgrim2017-10-081-8/+5
| | | | llvm-svn: 315187
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-0810-13/+2
| | | | llvm-svn: 315185
* [X86] getTargetConstantBitsFromNode - add support for decoding scalar constantsSimon Pilgrim2017-10-081-0/+7
| | | | llvm-svn: 315182
* [X86] Prefer MOVSS/SD over BLENDI during legalization. Remove BLENDI ↵Craig Topper2017-10-083-92/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | versions of scalar arithmetic patterns Summary: We currently disable some converting of shuffles to MOVSS/MOVSD during legalization if SSE41 is enabled. But later during shuffle combining we go back to prefering MOVSS/MOVSD. Additionally we have patterns that look for BLENDIs to detect scalar arithmetic operations. I believe due to the combining using MOVSS/MOVSD these are unnecessary. Interestingly, we still codegen blend instructions even though lowering/isel emit movss/movsd instructions. Turns out machine CSE commutes them to blend, and then commuting those blends back into blends that are equivalent to the original movss/movsd. This patch fixes the inconsistency in legalization to prefer MOVSS/MOVSD. The one test change was caused by this change. The problem is that we have integer types and are mostly selecting integer instructions except for the shufps. This shufps forced the execution domain, but the vpblendw couldn't have its domain changed with a naive instruction swap. We could fix this by special casing VPBLENDW based on the immediate to widen the element type. The rest of the patch is removing all the excess scalar patterns. Long term we should probably add isel patterns to make MOVSS/MOVSD emit blends directly instead of relying on the double commute. We may also want to consider emitting movss/movsd for optsize. I also wonder if we should still use the VEX encoded blendi instructions even with AVX512. Blends have better throughput, and that may outweigh the register constraint. Reviewers: RKSimon, zvi Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38023 llvm-svn: 315181
* [AArch64][GlobalISel] Make G_PHI of p0 types legal.Amara Emerson2017-10-081-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D38621 llvm-svn: 315177
* [X86][SKX] Adding the scheduling information for the SKX target.Gadi Haber2017-10-083-2/+6952
| | | | | | | | | | | | | | | | | | Adding the scheduling information for the SkylakeServer (SKX) target. This patch adds the instruction scheduling information for the SkylakeServer (SKX) architecture target by adding the file X86SchedSkylakeServer.td located under the X86 Target. We used the scheduling information retrieved from the Skylake architects in order to create the file. The scheduling information includes latency, number of micro-Ops and used ports by each SKL instruction. The patch continues the scheduling replacement and insertion effort started with the SNB target in r310792, the HSW target in r311879 and the SkylakeClient (SKL) target in rL313613. Please expect some performance fluctuations due to code alignment effects. Reviewers: zvi, RKSimon, craig.topper, chandlerc, aymanmu Differential Revision: https://reviews.llvm.org/D38443 Change-Id: I5c228fcc09e9e5a99b6116e62b356c4f9b971185 llvm-svn: 315175
* [X86] Add missing entries in 'MemoryFoldTable2Addr' to get complete form of ↵Ayman Musa2017-10-081-0/+50
| | | | | | | | | | the table. Get the folding table 'MemoryFoldTable2Addr' to a complete state as part of the process explained in https://reviews.llvm.org/D38028 Differential Revision: https://reviews.llvm.org/D38500 llvm-svn: 315174
* [X86][TableGen] Recommitting the X86 memory folding tables TableGen backend ↵Ayman Musa2017-10-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | while disabling it by default. After the original commit ([[ https://reviews.llvm.org/rL304088 | rL304088 ]]) was reverted, a discussion in llvm-dev was opened on 'how to accomplish this task'. In the discussion we concluded that the best way to achieve our goal (which is to automate the folding tables and remove the manually maintained tables) is: # Commit the tablegen backend disabled by default. # Proceed with an incremental updating of the manual tables - while checking the validity of each added entry. # Repeat previous step until we reach a state where the generated and the manual tables are identical. Then we can safely remove the manual tables and include the generated tables instead. # Schedule periodical (1 week/2 weeks/1 month) runs of the pass: - if changes appear (new entries): - make sure the entries are legal - If they are not, mark them as illegal to folding - Commit the changes (if there are any). CMake flag added for this purpose is "X86_GEN_FOLD_TABLES". Building with this flags will run the pass and emit the X86GenFoldTables.inc file under build/lib/Target/X86/ directory which is a good reference for any developer who wants to take part in the effort of completing the current folding tables. Differential Revision: https://reviews.llvm.org/D38028 llvm-svn: 315173
* [X86] Stop LowerSIGN_EXTEND_AVX512 from creating v8i16/v16i16/v16i8 vselects ↵Craig Topper2017-10-081-1/+6
| | | | | | | | with a v8i1/v16i1 condition when BWI is not available. Some of the tests in vector-shuffle-v1.ll would get into an infinite loop without this. llvm-svn: 315172
* [X86] Add new attribute to X86 instructions to enable marking them as "not ↵Ayman Musa2017-10-085-42/+58
| | | | | | | | | | | memory foldable" This attribute will be used in a tablegen backend that generated the X86 memory folding tables which will be added in a future pass. Instructions with this attribute unset will be excluded from the full set of X86 instructions available for the pass. Differential Revision: https://reviews.llvm.org/D38027 llvm-svn: 315171
* [X86] Simplify some code in getInsertVINSERTImmediate and ↵Craig Topper2017-10-081-4/+2
| | | | | | | | getExtractVEXTRACTImmediate. NFC Replace one of the divides with a multiply. llvm-svn: 315162
* [X86] If we see an insert of a bitcast into zero vector, canonicalize it to ↵Craig Topper2017-10-082-1/+16
| | | | | | | | move the bitcast to the other side of the insert. This improves detection of zeroing of upper bits during isel. llvm-svn: 315161
* [X86] Remove ISD::INSERT_SUBVECTOR handling from combineBitcastForMaskedOp. ↵Craig Topper2017-10-082-23/+133
| | | | | | | | Add isel patterns to make up for it. This will allow for some flexibility in canonicalizing bitcasts around insert_subvector. llvm-svn: 315160
* [X86] Use getConstantOperandVal to simplify some code. NFCCraig Topper2017-10-081-3/+3
| | | | llvm-svn: 315159
* [X86][SSE] Match bitcasted BUILD_VECTOR of constants for v2i64 shifts on ↵Simon Pilgrim2017-10-071-2/+2
| | | | | | | | 64-bit targets (PR34855) Extension to rL315155, generate constant shifts on 64-bits as well as 32-bits. llvm-svn: 315156
* [X86][SSE] Match bitcasted v4i32 BUILD_VECTORS for v2i64 shifts on 64-bit ↵Simon Pilgrim2017-10-071-3/+2
| | | | | | | | targets (PR34855) We were already doing this for 32-bit targets, but we can generate these on 64-bits as well. llvm-svn: 315155
* [SelectionDAG} Use KnownBits::isUnknown and hasConflict. NFCCraig Topper2017-10-071-8/+8
| | | | llvm-svn: 315154
* [X86] Add X86ISD::CMOV to computeKnownBitsForTargetNode and ↵Craig Topper2017-10-071-0/+20
| | | | | | | | | | | | | | | | ComputeNumSignBitsForTargetNode. Summary: Implementations based on ISD::SELECT. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38663 llvm-svn: 315153
* [X86][SSE] Improve shuffling combining with horizontal operationsSimon Pilgrim2017-10-071-33/+33
| | | | | | | | | | Recognise cases when we can merge the shuffles with their horizontal (HADD/HSUB/PACK) instruction inputs. Replaces an older implementation which performed some of this during lowering, expanding an existing target shuffle combine stage instead. Differential Revision: https://reviews.llvm.org/D38506 llvm-svn: 315150
* [X86] Update an outdated comment about SjLjMartin Storsjo2017-10-071-6/+2
| | | | | | | | | The SjLj intrinsics in the X86 backend are intended for use with SjLj exception handling as well, since SVN r271244. Differential Revision: https://reviews.llvm.org/D38532 llvm-svn: 315146
* [X86] Correct result type for the flag result of RDSEED and RDRAND nodes. ↵Craig Topper2017-10-071-2/+2
| | | | | | | | Correct the CC type for the CMOV used with RDSEED/RDRAND. The flag result was MVT::Glue, but should be MVT::i32. The CC type was MVT::i8, but should be MVT::i32. llvm-svn: 315145
* [MachineOutliner] Disable outlining from LinkOnceODRs by defaultJessica Paquette2017-10-076-15/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Say you have two identical linkonceodr functions, one in M1 and one in M2. Say that the outliner outlines A,B,C from one function, and D,E,F from another function (where letters are instructions). Now those functions are not identical, and cannot be deduped. Locally to M1 and M2, these outlining choices would be good-- to the whole program, however, this might not be true! To mitigate this, this commit makes it so that the outliner sees linkonceodr functions as unsafe to outline from. It also adds a flag, -enable-linkonceodr-outlining, which allows the user to specify that they want to outline from such functions when they know what they're doing. Changing this handles most code size regressions in the test suite caused by competing with linker dedupe. It also doesn't have a huge impact on the code size improvements from the outliner. There are 6 tests that regress > 5% from outlining WITH linkonceodrs to outlining WITHOUT linkonceodrs. Overall, most tests either improve or are not impacted. Not outlined vs outlined without linkonceodrs: https://hastebin.com/raw/qeguxavuda Not outlined vs outlined with linkonceodrs: https://hastebin.com/raw/edepoqoqic Outlined with linkonceodrs vs outlined without linkonceodrs: https://hastebin.com/raw/awiqifiheb Numbers generated using compare.py with -m size.__text. Tests run for AArch64 with -Oz -mllvm -enable-machine-outliner -mno-red-zone. llvm-svn: 315136
* [InstCombine] use correct type when propagating constant condition in ↵Sanjay Patel2017-10-061-2/+3
| | | | | | simplifyDivRemOfSelectWithZeroOp (PR34856) llvm-svn: 315130
* [InstCombine] rename SimplifyDivRemOfSelect to be clearer, add comments, ↵Sanjay Patel2017-10-062-20/+20
| | | | | | | | | simplify code; NFCI There's at least one bug here - this code can fail with vector types (PR34856). It's also being called for FREM; I'm still trying to understand how that is valid. llvm-svn: 315127
* [AVX512] Fix TERNLOG when folding broadcastCameron McInally2017-10-061-4/+4
| | | | | | | | | Patch to fix ternlog instructions with a folded broadcast. The broadcast decorator, e.g. {1toX}, was missing. Differential Revision: https://reviews.llvm.org/D38649 llvm-svn: 315122
* [dwarfdump] Verify that unit type matches root DIEJonas Devlieghere2017-10-061-8/+24
| | | | | | | | | | | | | This patch adds two new verifiers: - It checks that the root DIE of a CU is actually a valid unit DIE. (based on its tag) - For DWARF5 which contains a unit type int he CU header, it checks that this matches the type of the unit DIE. Differential revision: https://reviews.llvm.org/D38453 llvm-svn: 315121
* Revert "Roll forward r314928"Reid Kleckner2017-10-062-238/+0
| | | | | | | | | | | | | | | | | | | | This appears to be miscompiling Clang, as shown on two Windows bootstrap bots: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/7611 http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/6870 Nothing else is in the blame list. Both emit errors on this valid code in the Windows ucrt headers: C:\...\ucrt\malloc.h:95:32: error: invalid operands to binary expression ('char *' and 'int') _Ptr = (char*)_Ptr + _ALLOCA_S_MARKER_SIZE; ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~ I am attempting to reproduce this now. This reverts r315044 llvm-svn: 315108
* [PEI] Remove required properties and use 'if' instead of std::functionReid Kleckner2017-10-061-49/+23
| | | | | | | | | | | | | | | | | | Summary: After r303360, we initialize UsesCalleeSaves in runOnMachineFunction, which runs after getRequiredProperties. UsesCalleeSaves was initialized to 'false', so getRequiredProperties would always return an empty set. We don't have a TargetMachine available early anymore after r303360. Just removing the requirement of NoVRegs seems to make things work, so let's do that. Reviewers: thegameg, dschuff, MatzeB Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D38597 llvm-svn: 315089
* Bitcode: add an auto-upgrade for LTO section nameSaleem Abdulrasool2017-10-063-1/+31
| | | | | | | | | | | The bitcode reader looks specifically for `__DATA, __objc_catlist` as a section name. However, SVN r304661 removed the spaces (the two names are functionally equivalent but do not compare equally lexicographically). This causes compatibility issues. Add an auto-upgrade path for removing the spaces as well as use the new name in the LTO plugin. llvm-svn: 315086
* [AMDGPU] New 64 bit div/rem expansionStanislav Mekhanoshin2017-10-061-19/+151
| | | | | | | | | | | Old expansion was 20 VGPRs, 78 SGPRs and ~380 instructions. This expansion is 11 VGPRs, 12 SGPRs and ~120 instructions. Passes OpenCL conformance test_integer_ops quick_[u]long_math Differential Revision: https://reviews.llvm.org/D38607 llvm-svn: 315081
* [MC] Use unique_ptr to manage WinFrameInfos, NFCReid Kleckner2017-10-062-16/+12
| | | | | | | | The FrameInfo cannot be stored directly in the vector because chained frames may refer to parent frames, so we need pointers that are stable across a vector resize. llvm-svn: 315080
* Support: Rewrite Windows implementation of sys::fs::rename to be more POSIXy.Peter Collingbourne2017-10-061-47/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of rename uses ReplaceFile if the destination file already exists. According to the documentation for ReplaceFile, the source file is opened without a sharing mode. This means that there is a short interval of time between when ReplaceFile renames the file and when it closes the file during which the destination file cannot be opened. This behaviour is not POSIX compliant because rename is supposed to be atomic. It was also causing intermittent link failures when linking with a ThinLTO cache; the ThinLTO cache implementation expects all cache files to be openable. This patch addresses that problem by re-implementing rename using CreateFile and SetFileInformationByHandle. It is roughly a reimplementation of ReplaceFile with a better sharing policy as well as support for renaming in the case where the destination file does not exist. This implementation is still not fully POSIX. Specifically in the case where the destination file is open at the point when rename is called, there will be a short interval of time during which the destination file will not exist. It isn't clear whether it is possible to avoid this using the Windows API. Differential Revision: https://reviews.llvm.org/D38570 llvm-svn: 315079
* Directly return promoted direct call instead of rely on stripPointerCast.Dehao Chen2017-10-062-11/+15
| | | | | | | | | | | | | | Summary: stripPointerCast is not reliably returning the value that's being type-casted. Instead it may look further at function attributes to further propagate the value. Instead of relying on stripPOintercast, the more reliable solution is to directly use the pointer to the promoted direct call. Reviewers: tejohnson, davidxl Reviewed By: tejohnson Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38603 llvm-svn: 315077
* [ARM] GlobalISel: Select shiftsDiana Picus2017-10-061-0/+16
| | | | | | | | | Unfortunately TableGen doesn't handle this yet: Unable to deduce gMIR opcode to handle Src (which is a leaf). Just add some temporary hand-written code to generate the proper MOVsr. llvm-svn: 315071
* [ARM] GlobalISel: Map shift operands to GPRsDiana Picus2017-10-061-0/+3
| | | | llvm-svn: 315067
* [llvm-dsymutil] Add support for __swift_ast MachO DWARF sectionFrancis Ricci2017-10-061-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging, and which contains a byte-for-byte dump of the swiftmodule file. Add this feature to llvm-dsymutil. Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of `__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil (Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the __swift_ast section). Reviewers: aprantl, friss Subscribers: llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D38504 llvm-svn: 315066
* [ARM] GlobalISel: Mark shifts as legal for s32Diana Picus2017-10-061-0/+3
| | | | | | | The new legalize combiner introduces shifts all over the place, so we should support them sooner rather than later. llvm-svn: 315064
OpenPOWER on IntegriCloud