summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [OPENMP 4.5] Allow data members as loop counters in loop-basedAlexey Bataev2016-04-012-166/+289
| | | | | | | | | | directives. OpenMP 4.5 allows privatization of non-static data members in non-static member functions. Patch allows to use and implicit privatization of data members used as counters in loop-based directives. llvm-svn: 265121
* [AArch64] Better errors for out-of-range fixupsOliver Stannard2016-04-013-25/+110
| | | | | | | | | When a fixup that can be resolved by the assembler is out of range, we should report an error in the source, rather than crashing. Differential Revision: http://reviews.llvm.org/D18402 llvm-svn: 265120
* Revert "[OPENMP] Allow skip expression after comma in clauses with lists."Alexey Bataev2016-04-0192-208/+219
| | | | | | | This reverts commit http://reviews.llvm.org/rL265003. After some thoughts decided to emit errors here. llvm-svn: 265119
* ThinLTO: move ObjCARCContractPass in the CodeGen pipelineMehdi Amini2016-04-011-1/+6
| | | | | | | This is to be coherent with Full LTO. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265118
* [clang-tidy] Don't delete unused parameter in class override method in ↵Haojian Wu2016-04-012-10/+22
| | | | | | | | | | | | | | anonymous namespace. Summary: Fixes PR26740. Reviewers: alexfh Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D17926 llvm-svn: 265117
* [OCaml] Use LLVMCreateMessage with constant strings when calling llvm_raiseJeroen Ketema2016-04-014-4/+7
| | | | | | | | | | | The llvm_string_of_message function, called by llvm_raise, calls LLVMDisposeMessage, which expects the message to be dynamically allocated; it fails freeing the message otherwise. So always dynamically allocate with LLVMCreateMessage. Differential Revision: http://reviews.llvm.org/D18675 llvm-svn: 265116
* [OCaml] Reinstate data_layoutJeroen Ketema2016-04-014-0/+12
| | | | | | | | | | | | Expose LLVMCreateTargetMachineData as data_layout. As r263530 did for go. From that commit: "LLVMGetTargetDataLayout was removed from the C API, and then TargetMachine.TargetData was removed. Later, LLVMCreateTargetMachineData was added to the C API" Differential Revision: http://reviews.llvm.org/D18677 llvm-svn: 265115
* ScoPDetection: Obtain a known free diagnostic IDTobias Grosser2016-04-011-1/+2
| | | | | | | | | ... instead of hardcoding something that has been free at some point. This fixes a crash triggered by r265084, where the diagnostic IDs have been shifted in a way that resulted our hardcode ID to not be assigned any implementation. Our ID was likely already wrong earlier on, but this time we really crashed nicely. llvm-svn: 265114
* Add a libLTO API to stop/restart ThinLTO between optimizations and CodeGenMehdi Amini2016-04-015-5/+83
| | | | | | | | This allows the linker to instruct ThinLTO to perform only the optimization part or only the codegen part of the process. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265113
* [PPC64] Bug fix: when enabling sibling-call-opt and shrink-wrapping, the ↵Chuang-Yu Cheng2016-04-012-26/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tail call branch instruction might disappear Bug Pattern: # BB#0: # %entry cmpldi 3, 0 beq- 0, .LBB0_2 # BB#1: # %exit lwz 4, 0(3) #TC_RETURNd8 LVComputationKind 0 .LBB0_2: # %cond.false mflr 0 std 0, 16(1) stdu 1, -96(1) .Ltmp0: .cfi_def_cfa_offset 96 .Ltmp1: .cfi_offset lr, 16 bl __assert_fail nop The branch instruction for tail call return is not generated, because the shrink-wrapping pass choosing a new Restore Point: %cond.false, so %exit block is not sent to emitEpilogue, that's why the branch is not generated. Thanks Kit's opinions! Reviewers: nemanjai hfinkel tjablin kbarton http://reviews.llvm.org/D17606 llvm-svn: 265112
* Add a module Hash in the bitcode and the combined index, implementing a kind ↵Mehdi Amini2016-04-0112-38/+236
| | | | | | | | | | | | | of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 This is a recommit of r265095 after fixing the Windows issues. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265111
* Fix MSVC warning "comparison of integers of different signs" (NFC)Mehdi Amini2016-04-011-1/+1
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265110
* Fix S390 big endian detectionMehdi Amini2016-04-011-2/+3
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265109
* Const correctness in raw_sha1_ostream (NFC)Mehdi Amini2016-04-011-1/+1
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265108
* Add support for computing SHA1 in LLVMMehdi Amini2016-04-016-0/+363
| | | | | | | | | | | | | | | | Provide a class to generate a SHA1 from a sequence of bytes, and a convenience raw_ostream adaptor. This will be used to provide a "build-id" by hashing the Module block when writing bitcode. ThinLTO will use this information for incremental build. Reapply r265094 which was reverted in r265102 because it broke MSVC bots (constexpr is not supported). http://reviews.llvm.org/D16325 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265107
* Improve CHECK-NOT robustness of dllexport testsSean Silva2016-04-012-5/+20
| | | | | | | | | | | | | This changes some dllexport tests, to verify that some symbols that should not be exported are not, in a way that improves the robustness of CHECK-SAME interaction with CHECK-NOT. We plan to enable dllimport/dllexport support for the PS4, and these changes are for points we noticed in our internal testing. Patch by Warren Ristow! llvm-svn: 265106
* Use range-based for loops. NFC.Michael Kuperstein2016-04-011-6/+5
| | | | llvm-svn: 265105
* Visual Studio native visualizers for clang::TemplateSpecializationTypeMike Spertus2016-04-011-2/+17
| | | | | | | | Displays a template specialization as, say, A<int, double>. Does not yet handle UncommonTemplateNameStorage, QualifiedTemplateName, or DependentTemplateName, but still more than worthwhile llvm-svn: 265104
* [analyzer] Prefer accessor method in extension over category in CallEvent.Devin Coughlin2016-04-012-2/+73
| | | | | | | | | | | | | | In ObjCMethodCall:getRuntimeDefinition(), if the method is an accessor in a category, and it doesn't have a self declaration, first try to find the method in a class extension. This works around a bug in Sema where multiple accessors are synthesized for properties in class extensions that are redeclared in a category. The implicit parameters are not filled in for the method on the category, which causes a crash when trying to synthesize a getter for the property in BodyFarm. The Sema bug is tracked as rdar://problem/25481164. rdar://problem/25056531 llvm-svn: 265103
* Revert "Add support for computing SHA1 in LLVM"Mehdi Amini2016-04-0118-597/+38
| | | | | | | | This reverts commit r265096, r265095, and r265094. Windows build is broken, and the validation does not pass. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265102
* Don't insert stackrestore on deoptimizing returnsSanjoy Das2016-04-012-2/+20
| | | | | | | | They're not necessary (since the stack pointer is trivially restored on return), and the way LLVM inserts the stackrestore calls breaks the IR (we get a stackrestore between the deoptimize call and the return). llvm-svn: 265101
* Don't insert lifetime end markers on deoptimizing returnsSanjoy Das2016-04-012-2/+21
| | | | | | | | | They're not necessary (since the lifetime of the alloca is trivially over due to the return), and the way LLVM inserts the lifetime.end markers breaks the IR (we get a lifetime end marker between the deoptimize call and the return). llvm-svn: 265100
* Don't use an i64 return type with webkit_jsccSanjoy Das2016-04-012-10/+11
| | | | | | | | | Re-enable an assertion enabled by Justin Lebar in rL265092. rL265092 was breaking test/CodeGen/X86/deopt-intrinsic.ll because webkit_jscc does not like non-i64 return types. Change the test case to not do that. llvm-svn: 265099
* AArch64ISelLowering: Remove unused variables/arguments; NFCMatthias Braun2016-04-012-5/+1
| | | | llvm-svn: 265098
* Fix Sub-register Rewriting in Aggressive Anti-Dependence BreakerChuang-Yu Cheng2016-04-012-13/+40
| | | | | | | | | | | | | | | | | | | Previously, HandleLastUse would delete RegRef information for sub-registers if they were dead even if their corresponding super-register were still live. If the super-register were later renamed, then the definitions of the sub-register would not be updated appropriately. This patch alters the behavior so that RegInfo information for sub-registers is only deleted when the sub-register and super-register are both dead. This resolves PR26775. This is the mirror image of Hal's r227311 commit. Author: Tom Jablin (tjablin) Reviewers: kbarton uweigand nemanjai hfinkel http://reviews.llvm.org/D18448 llvm-svn: 265097
* Add missing test for the "Module hash in bitcode" added in r265095Mehdi Amini2016-04-011-0/+4
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265096
* Add a module Hash in the bitcode and the combined index, implementing a kind ↵Mehdi Amini2016-04-0111-38/+232
| | | | | | | | | | | of "build-id" This is intended to be used for ThinLTO incremental build. Differential Revision: http://reviews.llvm.org/D18213 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265095
* Add support for computing SHA1 in LLVMMehdi Amini2016-04-016-0/+361
| | | | | | | | | | | Provide a class to generate a SHA1 from a sequence of bytes, and a convenience raw_ostream adaptor. This will be used to provide a "build-id" by hashing the Module block when writing bitcode. ThinLTO will use this information for incremental build. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265094
* Revert "Protect some assertions with NDEBUG rather than DEBUG()."Justin Lebar2016-04-011-7/+6
| | | | | | This reverts r265092, because it breaks CodeGen/X86/deopt-intrinsic.ll. llvm-svn: 265093
* Protect some assertions with NDEBUG rather than DEBUG().Justin Lebar2016-04-011-6/+7
| | | | | | | DEBUG() only runs if you pass -debug, but these assertions are generally useful. llvm-svn: 265092
* [NVPTX] Add a truncate DAG node to some calls.Justin Lebar2016-04-011-2/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we were running afoul of the assertion EVT(CLI.Ins[i].VT) == InVals[i].getValueType() && "LowerCall emitted a value with the wrong type!" in SelectionDAGBuilder.cpp when running the NVPTX/i8-param.ll test. This is because our backend (for some reason) treats small return values as i32, but it wasn't ever truncating the i32 back down to the expected width in the DAG. Unclear to me whether this fixes any actual bugs -- in this test, at least, the generated code is unchanged. Reviewers: jingyue Subscribers: llvm-commits, tra, jholewinski Differential Revision: http://reviews.llvm.org/D17872 llvm-svn: 265091
* [NVPTX] Read __CUDA_FTZ from module flags in NVVMReflect.Justin Lebar2016-04-012-7/+30
| | | | | | | | | | | | | | | | | | | Summary: Previously the NVVMReflect pass would read its configuration from command-line flags or a static configuration given to the pass at instantiation time. This doesn't quite work for clang's use-case. It needs to pass a value for __CUDA_FTZ down on a per-module basis. We use a module flag for this, so the NVVMReflect pass needs to be updated to read said flag. Reviewers: tra, rnk Subscribers: cfe-commits, jholewinski Differential Revision: http://reviews.llvm.org/D18672 llvm-svn: 265090
* [NVPTX] Annotate some instructions as hasSideEffects = 0.Justin Lebar2016-04-012-146/+171
| | | | | | | | | | | | | | | | | | | | Summary: Tablegen tries to infer this from the selection DAG patterns defined for the instructions, but it can't always. An instructive example is CLZr64. CLZr32 is correctly inferred to have no side-effects, but the selection DAG pattern for CLZr64 is slightly more complicated, and in particular the ctlz DAG node is not at the root of the pattern. Thus tablegen can't infer that CLZr64 has no side-effects. Reviewers: jholewinski Subscribers: jholewinski, tra, llvm-commits Differential Revision: http://reviews.llvm.org/D17472 llvm-svn: 265089
* [ifcnv] Add brief comment explaining what ifcnv is.Justin Lebar2016-04-011-1/+2
| | | | llvm-svn: 265088
* Fix Windows build (typo in disk_space() implementation)Mehdi Amini2016-04-011-1/+1
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265087
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-016-9/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling: rnb_err_t RNBRemote::HandlePacket_stop_process (const char *p) { if (!DNBProcessInterrupt(m_ctx.ProcessID())) HandlePacket_last_signal (NULL); return rnb_success; } In the call to DNBProcessInterrupt we did: nub_bool_t DNBProcessInterrupt(nub_process_t pid) { MachProcessSP procSP; if (GetProcessSP (pid, procSP)) return procSP->Interrupt(); return false; } This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response. To fix this I did the following: 1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines 2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen 3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply. 5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response. 6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() 7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process. The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (incorrect extra stop reply packet) --> c <-- OK (response from z0 packet) Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets) <-- OK -- (we are back on track as this is a valid response to z0) ... As time goes on we should add more packet validators. <rdar://problem/22859505> llvm-svn: 265086
* [LTO] Inherit options from Codegen before initializing TargetMachine.Davide Italiano2016-04-012-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes bootstrap of llvm-tblgen (with LTO) and PR27150. Slightly longer explanation follows. Emission of .init_array instead of .ctors is supported only on a subset of the Target LLVM supports. Codegen needs to be conservative and always emit .ctors unless instructed otherwise (based on target). If the dynamic linker sees .init_array it completely ignores what's inside .ctors and therefore some constructors are not called (and this causes llvm-tblgen to crash on startup). Teach LLD/LTO about the Codegen options so we end up always emitting .init_array and avoid this issue. In future, we might end up supporting mix of .ctors and .init_array in different input files if this shows up as a real-world use case. The way gold handles this case is mapping .ctors from input into .init_array in output. There's also another caveat because as far as I understand .ctors run in reverse order so when we do the copy/mapping we need to reverse copy in the output if there's more than one ctor. That's why I'd rather avoid this complicate logic unless there's a real need. An analogous reasoning holds for .dtors/.fini_array. llvm-svn: 265085
* [LoopVectorize] Don't unconditionally print vectorization diagnosticsAkira Hatanaka2016-04-013-23/+60
| | | | | | | | | | | | | | | | | when compiling with LTO. r244523 a new class DiagnosticInfoOptimizationRemarkAnalysisAliasing for optimization analysis remarks related to pointer aliasing without guarding it in isDiagnosticEnabled in LLVMContext.cpp. This caused the diagnostic message to be printed unconditionally when compiling with LTO. This commit cleans up isDiagnosticEnabled and makes sure all the vectorization optimization remarks are guarded. rdar://problem/25382153 llvm-svn: 265084
* [CUDA] Fix typo in __clang_cuda_runtime_wrapper.h.Justin Lebar2016-04-011-1/+1
| | | | | | We're #including the wrong file! llvm-svn: 265083
* Add disk_space() to llvm::fsMehdi Amini2016-04-013-1/+56
| | | | | | | | | | Summary: Adapted from Boost::filesystem. (This is a reapply by reverting commit r265080 and fixing the WinAPI part) Differential Revision: http://reviews.llvm.org/D18467 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265082
* testcase gardening: update the emissionKind enum to the new syntax. (NFC)Adrian Prantl2016-04-01481-498/+498
| | | | llvm-svn: 265081
* Revert "Add disk_space() to llvm::fs"Mehdi Amini2016-04-013-56/+1
| | | | | | | | This reverts commit r265074 and r265068. Breaks windows build From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265080
* Fix a captialization error in r265077.Adrian Prantl2016-04-011-1/+1
| | | | llvm-svn: 265079
* Adapt to LLVM API change in r265077.Adrian Prantl2016-03-312-4/+4
| | | | | | | | | EmissionKind moved from DIBuilder to DICompileUnit. <rdar://problem/25427165> llvm-svn: 265078
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-31216-236/+319
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Follow-up to r265036: I got these iterators mixed upHans Wennborg2016-03-311-2/+2
| | | | llvm-svn: 265076
* clang-format the large enum definitions in LLVMBitCodes.hMehdi Amini2016-03-311-447/+447
| | | | | | | Suggestion from Duncan in a review thread. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265075
* Use const ref instead of value for Twine in the disk_space() APIMehdi Amini2016-03-313-3/+3
| | | | | | | Thanks Rui for noticing! From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265074
* ELF: Correctly handle --whole-archive for thin archives.Peter Collingbourne2016-03-314-1/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D18669 llvm-svn: 265073
* Update release notes with list of checks added since 3.8.Eugene Zelenko2016-03-315-15/+104
| | | | | | | | Fix some checks documentation style. Differential revision: http://reviews.llvm.org/D18582 llvm-svn: 265072
OpenPOWER on IntegriCloud