summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [DAG] check more operands for cycles when merging stores.Tim Northover2018-10-241-8/+8
| | | | | | | | | | | | | | | | | Until now, we've only checked whether merging stores would cause a cycle via the value argument, but the address and indexed offset arguments are also capable of creating cycles in some situations. The addresses are all base+offset with notionally the same base, but the base SDNode may still be different (e.g. via an indexed load in one case, and an ISD::ADD elsewhere). This allows cycles to creep in if one of these sources depends on another. The indexed offset is usually undef (representing a non-indexed store), but on some architectures (e.g. 32-bit ARM-mode ARM) it can be an arbitrary value, again allowing dependency cycles to creep in. llvm-svn: 345200
* Revert "Teach __libcpp_is_floating_point that __fp16 and _Float16 are"Petr Hosek2018-10-242-30/+0
| | | | | | | | | This reverts commits r333103 and r333108. _Float16 and __fp16 are C11 extensions and compilers other than Clang don't define these for C++. Differential Revision: https://reviews.llvm.org/D53670 llvm-svn: 345199
* Add gfx909 to GPU ArchTim Renouf2018-10-243-0/+7
| | | | | | | | Subscribers: jholewinski, cfe-commits Differential Revision: https://reviews.llvm.org/D53558 llvm-svn: 345198
* [X86] Add *SP to tailcall register class to fix verifier errorReid Kleckner2018-10-246-32/+54
| | | | | | | | | It's possible to do a tail call to a stack argument. LLVM already calculates the right stack offset to call through. Fixes the sibcall* and musttail* verifier failures tracked at PR27481. llvm-svn: 345197
* [MIR] Add hasWinCFI fieldSanjin Sijaric2018-10-243-0/+4
| | | | | | | | | Adding hasWinCFI field so that I can add MIR test cases to https://reviews.llvm.org/D50166. Differential Revision: https://reviews.llvm.org/D51201 llvm-svn: 345196
* [ExecutionEngine] Remove some dead code from JITEventListener.h.Lang Hames2018-10-241-22/+0
| | | | llvm-svn: 345195
* [clang-query] Refactor Output settings to booleansStephen Kelly2018-10-246-19/+45
| | | | | | | | | | | | Summary: This will make it possible to add non-exclusive mode output. Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53501 llvm-svn: 345194
* [clang-query] Add 'detailed-ast' output as an alias for 'dump'Stephen Kelly2018-10-245-10/+20
| | | | | | | | | | | | Summary: Future development can then dump other content than AST. Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53500 llvm-svn: 345193
* [clang-query] Re-word command helpStephen Kelly2018-10-241-5/+11
| | | | | | | | | | | | | | | | Summary: This will make it possible to easily * Add new commands which accept <feature> parameters * Extend the list of features Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53498 llvm-svn: 345192
* [clant-tidy] abseil: Add clangTooling to CMakeLists.txtHeejin Ahn2018-10-241-0/+1
| | | | | | Without this, builds with `-DBUILD_SHARED_LIBS=ON` fail. llvm-svn: 345191
* [llvm-mca] Replace InstRef::isValid with operator bool. NFC.Matt Davis2018-10-246-17/+12
| | | | llvm-svn: 345190
* [MC] Separate masm integer literal lexer support from inline asmReid Kleckner2018-10-2411-26/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This renames the IsParsingMSInlineAsm member variable of AsmLexer to LexMasmIntegers and moves it up to MCAsmLexer. This is the only behavior controlled by that variable. I added a public setter, so that it can be set from outside or from the llvm-mc command line. We may need to arrange things so that users can get this behavior from clang, but that's future work. I also put additional hex literal lexing functionality under this flag to fix PR32973. It appears that this hex literal parsing wasn't intended to be enabled in non-masm-style blocks. Now, masm integers (0b1101 and 0ABCh) work in __asm blocks from clang, but 0b label references work when using .intel_syntax in standalone .s files. However, 0b label references will *not* work from __asm blocks in clang. They will work from GCC inline asm blocks, which it sounds like is important for Crypto++ as mentioned in PR36144. Essentially, we only lex masm literals for inline asm blobs that use intel syntax. If the .intel_syntax directive is used inside a gnu-style inline asm statement, masm literals will not be lexed, which is compatible with gas and llvm-mc standalone .s assembly. This fixes PR36144 and PR32973. Reviewers: Gerolf, avt77 Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D53535 llvm-svn: 345189
* AArch64: add a pass to compress jump-table entries when possible.Tim Northover2018-10-2418-42/+693
| | | | llvm-svn: 345188
* [AArch64] Refactor Exynos machine model (NFC)Evandro Menezes2018-10-244-42/+42
| | | | llvm-svn: 345187
* [AArch64] Fix overlapping instructionsEvandro Menezes2018-10-241-5/+1
| | | | | | | Fix overlapping instruction descriptions in the machine model for Exynos M3. Effectively, NFC. llvm-svn: 345186
* [llvm-mca] Simplify the logic in FetchStage. NFCIAndrea Di Biagio2018-10-243-22/+18
| | | | | | Only method 'getNextInstruction()' needs to interact with the SourceMgr. llvm-svn: 345185
* Fix MSVC "truncation from 'double' to 'float'" warnings. NFCI.Simon Pilgrim2018-10-241-3/+3
| | | | llvm-svn: 345184
* [X86] Explicitly list all KNL features of inheriting from IVB. NFCCraig Topper2018-10-241-1/+23
| | | | | | I'm not sure all the microarchitectural tuning flags that have been added to IVBFeatures are relevant for KNL. Separating will allow us to see and audit them. There might even be some simplification opportunities in the Sandy Bridge through Icelake inheritance line without KNL using the same chain. llvm-svn: 345183
* [X86][SSE] Add SimplifyDemandedBitsForTargetNode PMULDQ/PMULUDQ handlingSimon Pilgrim2018-10-244-66/+70
| | | | | | | | | | Add X86 SimplifyDemandedBitsForTargetNode and use it to simplify PMULDQ/PMULUDQ target nodes. This enables us to repeatedly simplify the node's arguments after the previous approach had to be reverted due to PR39398. Differential Revision: https://reviews.llvm.org/D53643 llvm-svn: 345182
* AMDGPU: Handle gfx909 in AMDGPUTargetInfo::initFeatureMapKonstantin Zhuravlyov2018-10-243-0/+10
| | | | | | + add required tests llvm-svn: 345181
* Do not always request an implicit taskgroup region inside the kmpc_taskloop ↵Alexey Bataev2018-10-2411-36/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | function Summary: For the following code: ``` int i; #pragma omp taskloop for (i = 0; i < 100; ++i) {} #pragma omp taskloop nogroup for (i = 0; i < 100; ++i) {} ``` Clang emits the following LLVM IR: ``` ... call void @__kmpc_taskgroup(%struct.ident_t* @0, i32 %0) %2 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates*)* @.omp_task_entry. to i32 (i32, i8*)*)) ... call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %2, i32 1, i64* %8, i64* %9, i64 %13, i32 0, i32 0, i64 0, i8* null) call void @__kmpc_end_taskgroup(%struct.ident_t* @0, i32 %0) ... %15 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates.1*)* @.omp_task_entry..2 to i32 (i32, i8*)*)) ... call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %15, i32 1, i64* %21, i64* %22, i64 %26, i32 0, i32 0, i64 0, i8* null) ``` The first set of instructions corresponds to the first taskloop construct. It is important to note that the implicit taskgroup region associated with the taskloop construct has been materialized in our IR: the `__kmpc_taskloop` occurs inside a taskgroup region. Note also that this taskgroup region does not exist in our second taskloop because we are using the `nogroup` clause. The issue here is the 4th argument of the kmpc_taskloop call, starting from the end, is always a zero. Checking the LLVM OpenMP RT implementation, we see that this argument corresponds to the nogroup parameter: ``` void __kmpc_taskloop(ident_t *loc, int gtid, kmp_task_t *task, int if_val, kmp_uint64 *lb, kmp_uint64 *ub, kmp_int64 st, int nogroup, int sched, kmp_uint64 grainsize, void *task_dup); ``` So basically we always tell to the RT to do another taskgroup region. For the first taskloop, this means that we create two taskgroup regions. For the second example, it means that despite the fact we had a nogroup clause we are going to have a taskgroup region, so we unnecessary wait until all descendant tasks have been executed. Reviewers: ABataev Reviewed By: ABataev Subscribers: rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D53636 llvm-svn: 345180
* [TargetLowering] Add SimplifyDemandedBitsForTargetNode callbackSimon Pilgrim2018-10-242-1/+36
| | | | | | | | Add a SimplifyDemandedBitsForTargetNode callback to handle target nodes. Differential Revision: https://reviews.llvm.org/D53643 llvm-svn: 345179
* [hot-cold-split] Name split functions with ".cold" suffixTeresa Johnson2018-10-2435-79/+94
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current default of appending "_"+entry block label to the new extracted cold function breaks demangling. Change the deliminator from "_" to "." to enable demangling. Because the header block label will be empty for release compile code, use "extracted" after the "." when the label is empty. Additionally, add a mechanism for the client to pass in an alternate suffix applied after the ".", and have the hot cold split pass use "cold."+Count, where the Count is currently 1 but can be used to uniquely number multiple cold functions split out from the same function with D53588. Reviewers: sebpop, hiraditya Subscribers: llvm-commits, erik.pilkington Differential Revision: https://reviews.llvm.org/D53534 llvm-svn: 345178
* [OPENMP]Fix PR39366: do not try to private field if it is not captured.Alexey Bataev2018-10-242-2/+21
| | | | | | | | | The compiler is crashing if we trying to post-capture the fields implicitly captured inside of the task constructs. Seems, this kind of processing is not supported and such fields should not be firstprivatized. llvm-svn: 345177
* [CodeGen] Update test checks missed in r345168.Craig Topper2018-10-242-41/+41
| | | | | | These tests don't run unless the aarch64 target is registered and my testing had been on an x86 only build directory. llvm-svn: 345176
* [CostModel][X86] Add vXi8 vector division by constants costs.Simon Pilgrim2018-10-244-193/+209
| | | | | | ISD::MULHS/ISD::MULHU lowering of vXi8 types means we expand these in TargetLowering BuildSDIV/BuildUDIV. llvm-svn: 345175
* [sanitizer] Avoid calling a nullptr in MonotonicNanoTime if interceptors are ↵Kuba Mracek2018-10-241-2/+5
| | | | | | | | | | not yet initialized There's a TSan startup crash on Linux when used in Swift programs, where MonotonicNanoTime will try to call real_clock_gettime and then jump to NULL because interceptors are not yet initialized. This is on Ubuntu 18.04. Looks like TSan's main Initialize() function is called at a point where __progname is already set, but interceptors aren't yet set up. Let's fix this by checking whether interceptors are initialized in MonotonicNanoTime. Differential Revision: https://reviews.llvm.org/D53528 llvm-svn: 345174
* Fix use of libc++ specific macro in support/test_macros.hEric Fiselier2018-10-241-3/+4
| | | | llvm-svn: 345173
* Include input section name and output section name in an error message.Rui Ueyama2018-10-242-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D53645 llvm-svn: 345172
* ARM: Use BKPT instead of TRAP to implement llvm.debugtrap.Peter Collingbourne2018-10-246-9/+82
| | | | | | | | | | | | | | | | | | | | | The BKPT instruction is specified to cause a software breakpoint, and at least on Linux results in a SIGTRAP. This makes it more suitable for implementing debugtrap than TRAP (aka UDF #254), which is specified to cause an undefined instruction exception and results in a SIGILL on Linux. Moreover, BKPT is not marked as a terminator, which is not only consistent with the IR instruction but allows the analyzeBlock function to correctly analyze a basic block containing the instruction, which fixes an assertion failure in the machine block placement pass previously triggered by the included test case. Because BKPT is only supported starting with ARMv5T, we continue to use UDF #254 when targeting v4T. Differential Revision: https://reviews.llvm.org/D53614 llvm-svn: 345171
* [Hexagon] Flip hexagon-autohvx to be true by defaultKrzysztof Parzyszek2018-10-242-5/+5
| | | | | | | | | | | This will allow other generators of LLVM IR to use the auto-vectorizer without having to change that flag. Note: on its own, this patch will disable auto-vectorization on Hexagon in all cases, regardless of the -fvectorize flag. There is a companion LLVM patch that together with this one forms an NFC for clang users. llvm-svn: 345170
* [Hexagon] Flip hexagon-autohvx to be true by defaultKrzysztof Parzyszek2018-10-241-1/+1
| | | | | | | | | | | This will allow other generators of LLVM IR to use the auto-vectorizer without having to change that flag. Note: on its own, this patch will enable auto-vectorization on Hexagon in all cases, regardless of the -fvectorize flag. There is a companion clang patch that together with this one forms an NFC for clang users. llvm-svn: 345169
* [CodeGen] Update min-legal-vector width based on function argument and ↵Craig Topper2018-10-2417-591/+723
| | | | | | | | | | | | return types This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function so that we can restrict the backend type legalizer to prevent 512-bit vectors on SKX when -mprefer-vector-width=256 is specified if no explicit 512 bit vectors were specified by the user. This patch updates the vector width based on the argument and return types of the current function and from the types of any functions it calls. This is intended to make sure the backend type legalizer doesn't disturb any types that are required for ABI. Differential Revision: https://reviews.llvm.org/D52441 llvm-svn: 345168
* [clang-tidy] Add the abseil-duration-factory-float checkJonas Toth2018-10-248-0/+318
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This check finds cases where calls to an absl::Duration factory could use the more efficient integer overload. For example: // Original - Providing a floating-point literal. absl::Duration d = absl::Seconds(10.0); // Suggested - Use an integer instead. absl::Duration d = absl::Seconds(10); Patch by hwright. Reviewers: alexfh, hokein, aaron.ballman, JonasToth Reviewed By: hokein, JonasToth Subscribers: zturner, xazax.hun, Eugene.Zelenko, mgorny, cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D53339 llvm-svn: 345167
* [docs] Add rawspeed to test-suite proposals.Michael Kruse2018-10-241-0/+7
| | | | | | | rawspeed was suggested by Simon Pilgrim and Roman Lebedev in llvm.org/PR34216 and reviews.llvm.org/D46714. llvm-svn: 345166
* [X86] Bring back the MOV64r0 pseudo instructionCraig Topper2018-10-2417-472/+523
| | | | | | | | | | | | This patch brings back the MOV64r0 pseudo instruction for zeroing a 64-bit register. This replaces the SUBREG_TO_REG MOV32r0 sequence we use today. Post register allocation we will rewrite the MOV64r0 to a 32-bit xor with an implicit def of the 64-bit register similar to what we do for the various XMM/YMM/ZMM zeroing pseudos. My main motivation is to enable the spill optimization in foldMemoryOperandImpl. As we were seeing some code that repeatedly did "xor eax, eax; store eax;" to spill several registers with a new xor for each store. With this optimization enabled we get a store of a 0 immediate instead of an xor. Though I admit the ideal solution would be one xor where there are multiple spills. I don't believe we have a test case that shows this optimization in here. I'll see if I can try to reduce one from the code were looking at. There's definitely some other machine CSE(and maybe other passes) behavior changes exposed by this patch. So it seems like there might be some other deficiencies in SUBREG_TO_REG handling. Differential Revision: https://reviews.llvm.org/D52757 llvm-svn: 345165
* [CostModel][X86] Enable non-uniform vector division by constants costs.Simon Pilgrim2018-10-244-128/+660
| | | | | | Non-uniform division/remainder handling was added back at D49248/D50765 - so share the 'mul+sub' costs that already exist for uniform cases. llvm-svn: 345164
* [CodeGen] skip lifetime end marker in isInTailCallPositionRobert Lougher2018-10-242-0/+31
| | | | | | | | | A lifetime end intrinsic between a tail call and the return should not prevent the call from being tail call optimized. Differential Revision: https://reviews.llvm.org/D53519 llvm-svn: 345163
* [InstCombine] add test for ComputeNumSignBits with shuffle; NFCSanjay Patel2018-10-241-25/+58
| | | | llvm-svn: 345162
* [llvm-mca] Remove dependency from InstrBuilder in class InstructionTables.Andrea Di Biagio2018-10-246-12/+9
| | | | | | | | | Also, removed the initialization of vectors used for processor resource masks. Support function 'computeProcResourceMasks()' already calls method resize on those vectors. No functional change intended. llvm-svn: 345161
* CodeGen: extract some local variables in CFConstantString creation (NFC)Saleem Abdulrasool2018-10-241-19/+18
| | | | | | | Extract the reference to the ASTContext and Triple and use them throughout the function. This is simply a cosmetic cleanup while in the area. NFC. llvm-svn: 345160
* AST: unindent CFConstantStringDecl by inverting condition (NFC)Saleem Abdulrasool2018-10-241-42/+40
| | | | | | | Unindent the body of the function by inverting check at the top. This is in preparation for supporting CFString's new ABI with swift. NFC. llvm-svn: 345159
* [LegalizeDAG] ExpandLegalINT_TO_FP - cleanup UINT_TO_FP i64 -> f32 expansion.Simon Pilgrim2018-10-241-11/+12
| | | | | | | | Use SrcVT/DestVT types and correct shift type. Part of prep work for D52965 llvm-svn: 345158
* Revert rL345127: [LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-247-185/+54
| | | | | | | | | DW_RLE_offset_pair entries It broke BB: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/11671/consoleFull#434797663d489585b-5106-414a-ac11-3ff90657619c llvm-svn: 345157
* [InstCombine] add test for select with shuffled condition (PR37549); NFCSanjay Patel2018-10-241-0/+35
| | | | llvm-svn: 345156
* [lldb] Remove enableThreadSanitizer from shared Xcode schemesKuba Mracek2018-10-242-2/+0
| | | | | | This was probably committed accidentally and default Xcode builds of LLDB now have TSan on. Let's turn it off. llvm-svn: 345155
* Refactor assignFileOffsets. NFC.Rui Ueyama2018-10-241-30/+29
| | | | llvm-svn: 345154
* [clangd] Do not query index for new name completions.Kadir Cetinkaya2018-10-243-5/+16
| | | | | | | | | | | | Reviewers: sammccall Reviewed By: sammccall Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D53192 llvm-svn: 345153
* [clang] Introduce new completion context typesKadir Cetinkaya2018-10-245-26/+42
| | | | | | | | | | | | | | Summary: New name suggestions were being used in places where existing names should have been used, this patch tries to fix some of those situations. Reviewers: sammccall Reviewed By: sammccall Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D53191 llvm-svn: 345152
* IR: Optimize FunctionType::get to perform one hash lookup instead of two, NFCIKrasimir Georgiev2018-10-241-7/+13
| | | | | | | | | | | | | | Summary: This function was performing two hash lookups when a new function type was requested: first checking if it exists and second to insert it. This patch updates the function to perform a single hash lookup in this case by updating the value in the hash table in-place in case the function type was not there before. Reviewers: bkramer Reviewed By: bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53471 llvm-svn: 345151
OpenPOWER on IntegriCloud