summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-exegesis][NFC] Remove extra `llvm::` qualifications.Clement Courbet2019-10-0913-281/+250
| | | | | | | | | | | | Summary: First patch: in unit tests. Subscribers: nemanjai, tschuett, MaskRay, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68687 llvm-svn: 374157
* [mips] Set default float ABI to "soft" on FreeBSDSimon Atanasyan2019-10-095-9/+25
| | | | | | | | Initial patch by Kyle Evans. Fix PR43596 llvm-svn: 374154
* [DebugInfo] Enable call site debug info for ARM and AArch64Nikola Prica2019-10-093-4/+11
| | | | | | | | | | | | | | | | | ARM and AArch64 SelectionDAG support for tacking parameter forwarding register is implemented so we can allow clang invocations for those two targets. Beside that restrict debug entry value support to be emitted for LimitedDebugInfo info and FullDebugInfo. Other types of debug info do not have functions nor variables debug info. Reviewers: aprantl, probinson, dstenb, vsk Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D67004 llvm-svn: 374153
* [Sema] Emit diagnostics for uncorrected delayed typos at the end of TUIlya Biryukov2019-10-092-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of asserting all typos are corrected in the sema destructor. The sema destructor is not run in the common case of running the compiler with the -disable-free cc1 flag (which is the default in the driver). Having this assertion led to crashes in libclang and clangd, which are not reproducible when running the compiler. Asserting at the end of the TU could be an option, but finding all missing typo correction cases is hard and having worse diagnostics instead of a failing assertion is a better trade-off. For more discussion on this, see: https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html Reviewers: sammccall, rsmith Reviewed By: rsmith Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64799 llvm-svn: 374152
* Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'Ilya Biryukov2019-10-093-69/+1
| | | | | | | | | | | Also revert follow-up changes to the test. Reason: the patch breaks our internal clang-tidy integration. It's also unclear why we should use getRealPath instead of plumbing the VFS to SanitizerBlacklist, see original commit thread of cfe-commits for a discussion. llvm-svn: 374151
* [TableGen] Fix crash when using HwModes in CodeEmitterGenJames Molloy2019-10-092-1/+11
| | | | | | | | When an instruction has an encoding definition for only a subset of the available HwModes, ensure we just avoid generating an encoding rather than crash. llvm-svn: 374150
* [llvm-exegesis] Add missing std::move in rL374146.Clement Courbet2019-10-091-2/+2
| | | | | | | | | | | | This was breaking some bots: /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/include/llvm/Support/Error.h:483:5: required from ‘llvm::Expected<T>::Expected(OtherT&&, typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type*) [with OtherT = std::vector<llvm::exegesis::CodeTemplate>&; T = std::vector<llvm::exegesis::CodeTemplate>; typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type = void]’ /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:238:20: required from here /usr/include/c++/6/bits/stl_construct.h:75:7: error: use of deleted function ‘llvm::exegesis::CodeTemplate::CodeTemplate(const llvm::exegesis::CodeTemplate&)’ { ::new(static_cast<void*>(__p)) _T1(std::forward<_Args>(__args)...); } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm-svn: 374149
* Unify the two CRC implementationsHans Wennborg2019-10-0918-241/+155
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [llvm-exegesis][NFC] Fix rL374146.Clement Courbet2019-10-091-1/+1
| | | | | | Remove extra semicolon: Target.cpp:187:2: warning: extra ‘;’ [-Wpedantic] llvm-svn: 374147
* [llvm-exegesis] Explore LEA addressing modes.Clement Courbet2019-10-095-17/+145
| | | | | | | | | | | | | | | | | Summary: This will help for PR32326. This shows the well-known issue with `RBP` and `R13` as base registers. Reviewers: gchatelet Subscribers: tschuett, llvm-commits, RKSimon, andreadb Tags: #llvm Differential Revision: https://reviews.llvm.org/D68646 llvm-svn: 374146
* [lldb] Don't crash when the ASTImporter produces diagnostics but instead log ↵Raphael Isemann2019-10-091-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | them. When playing with the C++ module prototype I noticed I can get LLDB to crash by making a result type that depends on __make_integer_seq (a BuiltinTemplate) which is not supported by the ASTImporter yet. This causes the ASTImporter to emit a diagnostic when copying the type to the ScratchASTContext. As deporting the result type is done after we are done parsing and the Clang's diagnostic engine asserts that it can only be used during parsing, it crashes LLDB while trying to render the diagnostic in the HandleDiagnostic method of ClangDiagnosticManagerAdapter. This patch just moves the HandleDiagnostic call to Clang behind our check that we still have a DiagnosticManager (which we remove after parsing) which prevents the assert from firing. We also shouldn't ignore such diagnostics, so I added a log statement for them. There doesn't seem to way to test this as these diagnostic only happen when we copy a node that's not supported by the ASTImporter which should never happen once we can copy everything with the ASTImporter, so every test case we add here will eventually become invalid. (Note that most of this diff is just whitespace changes as we now use an early exit instead of a huge 'if' block). llvm-svn: 374145
* Revert r374139, "[dsymutil] Fix handling of common symbols in multiple ↵Jeremy Morse2019-10-095-72/+2
| | | | | | | | | object files." The added test files ("com", "com1.o", "com2.o") are reserved names on Windows, and makes 'git checkout' fail with a filesystem error. llvm-svn: 374144
* [llvm-exegesis][NFC] Remove unecessary `using llvm::` directives.Clement Courbet2019-10-093-13/+5
| | | | | | We've been in namespace llvm for at least a year. llvm-svn: 374143
* Use lld-link instead of llvm-dlltool to create an implibRui Ueyama2019-10-091-1/+1
| | | | | | Suggested by Martin Storsjö. llvm-svn: 374142
* [lld] Don't create hints-section if Hint/Name Table is emptyRui Ueyama2019-10-093-1/+23
| | | | | | | | | | | Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports only. Patch by Stefan Schmidt. Differential revision: https://reviews.llvm.org/D68352 llvm-svn: 374140
* [dsymutil] Fix handling of common symbols in multiple object files.Jonas Devlieghere2019-10-095-2/+72
| | | | | | | | | | | | | For common symbols the linker emits only a single symbol entry in the debug map. This caused dsymutil to not relocate common symbols when linking DWARF coming form object files that did not have this entry. This patch fixes that by keeping track of common symbols in the object files and synthesizing a debug map entry for them using the address from the main binary. Differential revision: https://reviews.llvm.org/D68680 llvm-svn: 374139
* [TypeSize] Fix module builds (cassert)Kristina Brooks2019-10-091-0/+1
| | | | | | | | TypeSize.h uses `assert` statements without including the <cassert> header first which leads to failures in modular builds. llvm-svn: 374138
* Optimize operator=(const basic_string&) for tail call.Eric Fiselier2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Martijn Vels (mvels@google.com) Reviewed as https://reviews.llvm.org/D68276 This is a non trivial win for externally templated assignment operator. x86 without tail call (current libc++) 0000000000000000 <std::string::operator=(std::string const&)>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 53 push %rbx 5: 50 push %rax 6: 48 89 fb mov %rdi,%rbx 9: 48 39 f7 cmp %rsi,%rdi c: 74 17 je 25 <std::string::operator=(std::string const&)+0x25> e: 0f b6 56 17 movzbl 0x17(%rsi),%edx 12: 84 d2 test %dl,%dl 14: 79 07 jns 1d <std::string::operator=(std::string const&)+0x1d> 16: 48 8b 56 08 mov 0x8(%rsi),%rdx 1a: 48 8b 36 mov (%rsi),%rsi 1d: 48 89 df mov %rbx,%rdi 20: e8 00 00 00 00 callq 25 <std::string::operator=(std::string const&)+0x25> 25: 48 89 d8 mov %rbx,%rax 28: 48 83 c4 08 add $0x8,%rsp 2c: 5b pop %rbx 2d: 5d pop %rbp 2e: c3 retq After: 0000000000000000 <std::string::operator=(std::string const&)>: 0: 48 39 f7 cmp %rsi,%rdi 3: 74 14 je 19 <std::string::operator=(std::string const&)+0x19> 5: 0f b6 56 17 movzbl 0x17(%rsi),%edx 9: 84 d2 test %dl,%dl b: 79 07 jns 14 <std::string::operator=(std::string const&)+0x14> d: 48 8b 56 08 mov 0x8(%rsi),%rdx 11: 48 8b 36 mov (%rsi),%rsi 14: e9 00 00 00 00 jmpq 19 <std::string::operator=(std::string const&)+0x19> 19: 48 89 f8 mov %rdi,%rax 1c: c3 retq Benchmark (pending per https://reviews.llvm.org/D67667) ``` BM_StringAssignStr_Empty_Opaque 6.23ns ± 0% 5.19ns ± 0% -16.70% (p=0.016 n=5+4) BM_StringAssignStr_Empty_Transparent 5.86ns ± 0% 5.14ns ± 0% -12.24% (p=0.008 n=5+5) BM_StringAssignStr_Small_Opaque 8.79ns ± 1% 7.69ns ± 0% -12.53% (p=0.008 n=5+5) BM_StringAssignStr_Small_Transparent 9.44ns ± 0% 8.00ns ± 0% -15.26% (p=0.008 n=5+5) BM_StringAssignStr_Large_Opaque 25.2ns ± 0% 24.3ns ± 0% -3.50% (p=0.008 n=5+5) BM_StringAssignStr_Large_Transparent 23.6ns ± 0% 22.5ns ± 0% -4.76% (p=0.008 n=5+5) BM_StringAssignStr_Huge_Opaque 319ns ± 5% 317ns ± 5% ~ (p=0.690 n=5+5) BM_StringAssignStr_Huge_Transparent 319ns ± 5% 317ns ± 5% ~ (p=0.421 n=5+5) BM_StringAssignAsciiz_Empty_Opaque 7.41ns ± 0% 7.77ns ± 0% +4.89% (p=0.008 n=5+5) BM_StringAssignAsciiz_Empty_Transparent 7.54ns ± 3% 7.30ns ± 0% -3.24% (p=0.008 n=5+5) BM_StringAssignAsciiz_Small_Opaque 9.87ns ± 0% 10.24ns ± 1% +3.76% (p=0.008 n=5+5) BM_StringAssignAsciiz_Small_Transparent 10.4ns ± 1% 9.8ns ± 2% -5.78% (p=0.008 n=5+5) BM_StringAssignAsciiz_Large_Opaque 30.1ns ± 0% 30.1ns ± 0% ~ (p=0.167 n=5+5) BM_StringAssignAsciiz_Large_Transparent 27.1ns ± 0% 27.4ns ± 0% +0.92% (p=0.016 n=4+5) BM_StringAssignAsciiz_Huge_Opaque 383ns ± 4% 382ns ± 4% ~ (p=0.548 n=5+5) BM_StringAssignAsciiz_Huge_Transparent 375ns ± 0% 380ns ± 0% +1.37% (p=0.029 n=4+4) BM_StringAssignAsciizMix_Opaque 14.0ns ± 0% 14.0ns ± 0% ~ (p=0.881 n=5+5) BM_StringAssignAsciizMix_Transparent 13.7ns ± 1% 13.8ns ± 0% ~ (p=0.056 n=5+5) ``` llvm-svn: 374137
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-096-29/+124
| | | | | | | | | | | | whose value is not ignored. We don't warn on all the cases that are deprecated: specifically, we choose to not warn for now if there are parentheses around the assignment but its value is not actually used. This seems like a more defensible rule, particularly for cases like sizeof(v = a), where the parens are part of the operand rather than the sizeof syntax. llvm-svn: 374135
* [c++20] Implement most of P1152R4.Richard Smith2019-10-097-2/+138
| | | | | | | | | | | | | | Diagnose some now-deprecated uses of volatile types: * as function parameter types and return types * as the type of a structured binding declaration * as the type of the lvalue operand of an increment / decrement / compound assignment operator This does not implement a check for the deprecation of simple assignments whose results are used; that check requires somewhat more complexity and will be addressed separately. llvm-svn: 374133
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-085-6/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* [cxx_status] Note that Clang has supported std::source_location sinceRichard Smith2019-10-081-1/+1
| | | | | | version 9. llvm-svn: 374131
* Factor out some duplication. NFC.Richard Smith2019-10-081-5/+3
| | | | llvm-svn: 374130
* gn build: unbreak libcxx build after r374116 by restoring gen_link_script.py ↵Nico Weber2019-10-082-1/+51
| | | | | | for gn llvm-svn: 374129
* [Docs] Fixes broken sphinx build - undefined labelDeForest Richards2019-10-081-3/+0
| | | | | | Removes label ref pointing to non-existent subsystem docs page. llvm-svn: 374128
* [clang-scan-deps] Improve string/character literal skippingAlex Lorenz2019-10-082-11/+73
| | | | | | | | | | | | | | | | The existing string/character literal skipping code in the dependency directives source minimizer has two issues: - It doesn't stop the scanning when a newline is reached before the terminating character, unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line. - It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character. This commit fixes both issues. Differential Revision: https://reviews.llvm.org/D68436 llvm-svn: 374127
* [IRGen] Emit lifetime markers for temporary struct allocasFrancis Visoiu Mistrih2019-10-082-0/+111
| | | | | | | | | | | | | | When passing arguments using temporary allocas, we need to add the appropriate lifetime markers so that the stack coloring passes can re-use the stack space. This patch keeps track of all the lifetime.start calls emited before the codegened call, and adds the corresponding lifetime.end calls after the call. Differential Revision: https://reviews.llvm.org/D68611 llvm-svn: 374126
* [sanitizer] Fix crypt.cpp on Android againVitaly Buka2019-10-082-6/+3
| | | | llvm-svn: 374125
* [IA] Add tests for a few other edge casesBill Wendling2019-10-081-0/+4
| | | | | | | Test with the last eight bits within the range [7F, FF] and with lower-case hex letters. llvm-svn: 374124
* [dsymutil] Improve verbose output (NFC)Jonas Devlieghere2019-10-082-30/+55
| | | | | | | | | | | | The verbose output for finding relocations assumed that we'd always dump the DIE after (which starts with a newline) and therefore didn't include one itself. However, this isn't always true, leading to garbled output. This patch adds a newline to the verbose output and adds a line that says that the DIE is being kept (which isn't obvious otherwise). It also adds a 0x prefix to the relocations. llvm-svn: 374123
* DebugInfo: Move LLE enum handling to .def to match RLE handlingDavid Blaikie2019-10-084-16/+37
| | | | llvm-svn: 374122
* Revert Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-13/+7
| | | | | | | This reverts r374117 (git commit 6399db2f6fd64fa250093368be40eb5ae3af513b) while inspecting bot breakage. llvm-svn: 374121
* [libc++] Workaround old versions of CMake that don't understand list(JOIN)Louis Dionne2019-10-081-1/+1
| | | | llvm-svn: 374120
* Fix crash or wrong code bug if a lifetime-extended temporary contains aRichard Smith2019-10-083-9/+28
| | | | | | | | | | | | | | "non-constant" value. If the constant evaluator evaluates part of a variable initializer, including the initializer for some lifetime-extended temporary, but fails to fully evaluate the initializer, it can leave behind wrong values for temporaries encountered in that initialization. Don't try to emit those from CodeGen! Instead, look at the values that constant evaluation produced if (and only if) it actually succeeds and we're emitting the lifetime-extending declaration's initializer as a constant. llvm-svn: 374119
* [OpenMP] Enable thread affinity on FreeBSDDavid Carlier2019-10-086-14/+51
| | | | | | | | | | Reviewers: chandlerc, jlpeyton, jdoerfert, dim Reviewed-By: dim Differential Revision: https://reviews.llvm.org/D68580 llvm-svn: 374118
* Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-7/+13
| | | | | | | | | | | | | | | | When ingesting aranges from a dSYM it makes sense to always trust the contents of the accelerator table since it always comes from dsymutil. According to Instruments, skipping the decoding of all CU DIEs to get at the DW_AT_ranges attribute removes ~3.5 seconds from setting a breakpoint by file/line when debugging clang with a dSYM. Interestingly on the wall clock the speedup is less noticeable, but still present. rdar://problem/56057688 Differential Revision: https://reviews.llvm.org/D68655 llvm-svn: 374117
* [libc++] Move the linker script generation step to CMakeLouis Dionne2019-10-084-92/+54
| | | | | | | | | | | | | | | | | | Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
* [sanitizer] Fix crypt.cpp test on DarwinVitaly Buka2019-10-082-4/+7
| | | | llvm-svn: 374115
* StopInfo/Mach: Delete PPC supportVedant Kumar2019-10-081-103/+0
| | | | | | | | | LLDB appears to have at least partial support for PPC, but PPC on Mach isn't a thing AFAIK. Differential Revision: https://reviews.llvm.org/D68661 llvm-svn: 374114
* [clang] enable_trivial_var_init_zero should not be Joined<>Vitaly Buka2019-10-081-1/+1
| | | | | | | | | | | | Reviewers: rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68610 llvm-svn: 374113
* [CVP} Replace SExt with ZExt if the input is known-non-negativeRoman Lebedev2019-10-082-6/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: zero-extension is far more friendly for further analysis. While this doesn't directly help with the shift-by-signext problem, this is not unrelated. This has the following effect on test-suite (numbers collected after the finish of middle-end module pass manager): | Statistic | old | new | delta | percent change | | correlated-value-propagation.NumSExt | 0 | 6026 | 6026 | +100.00% | | instcount.NumAddInst | 272860 | 271283 | -1577 | -0.58% | | instcount.NumAllocaInst | 27227 | 27226 | -1 | 0.00% | | instcount.NumAndInst | 63502 | 63320 | -182 | -0.29% | | instcount.NumAShrInst | 13498 | 13407 | -91 | -0.67% | | instcount.NumAtomicCmpXchgInst | 1159 | 1159 | 0 | 0.00% | | instcount.NumAtomicRMWInst | 5036 | 5036 | 0 | 0.00% | | instcount.NumBitCastInst | 672482 | 672353 | -129 | -0.02% | | instcount.NumBrInst | 702768 | 702195 | -573 | -0.08% | | instcount.NumCallInst | 518285 | 518205 | -80 | -0.02% | | instcount.NumExtractElementInst | 18481 | 18482 | 1 | 0.01% | | instcount.NumExtractValueInst | 18290 | 18288 | -2 | -0.01% | | instcount.NumFAddInst | 139035 | 138963 | -72 | -0.05% | | instcount.NumFCmpInst | 10358 | 10348 | -10 | -0.10% | | instcount.NumFDivInst | 30310 | 30302 | -8 | -0.03% | | instcount.NumFenceInst | 387 | 387 | 0 | 0.00% | | instcount.NumFMulInst | 93873 | 93806 | -67 | -0.07% | | instcount.NumFPExtInst | 7148 | 7144 | -4 | -0.06% | | instcount.NumFPToSIInst | 2823 | 2838 | 15 | 0.53% | | instcount.NumFPToUIInst | 1251 | 1251 | 0 | 0.00% | | instcount.NumFPTruncInst | 2195 | 2191 | -4 | -0.18% | | instcount.NumFSubInst | 92109 | 92103 | -6 | -0.01% | | instcount.NumGetElementPtrInst | 1221423 | 1219157 | -2266 | -0.19% | | instcount.NumICmpInst | 479140 | 478929 | -211 | -0.04% | | instcount.NumIndirectBrInst | 2 | 2 | 0 | 0.00% | | instcount.NumInsertElementInst | 66089 | 66094 | 5 | 0.01% | | instcount.NumInsertValueInst | 2032 | 2030 | -2 | -0.10% | | instcount.NumIntToPtrInst | 19641 | 19641 | 0 | 0.00% | | instcount.NumInvokeInst | 21789 | 21788 | -1 | 0.00% | | instcount.NumLandingPadInst | 12051 | 12051 | 0 | 0.00% | | instcount.NumLoadInst | 880079 | 878673 | -1406 | -0.16% | | instcount.NumLShrInst | 25919 | 25921 | 2 | 0.01% | | instcount.NumMulInst | 42416 | 42417 | 1 | 0.00% | | instcount.NumOrInst | 100826 | 100576 | -250 | -0.25% | | instcount.NumPHIInst | 315118 | 314092 | -1026 | -0.33% | | instcount.NumPtrToIntInst | 15933 | 15939 | 6 | 0.04% | | instcount.NumResumeInst | 2156 | 2156 | 0 | 0.00% | | instcount.NumRetInst | 84485 | 84484 | -1 | 0.00% | | instcount.NumSDivInst | 8599 | 8597 | -2 | -0.02% | | instcount.NumSelectInst | 45577 | 45913 | 336 | 0.74% | | instcount.NumSExtInst | 84026 | 78278 | -5748 | -6.84% | | instcount.NumShlInst | 39796 | 39726 | -70 | -0.18% | | instcount.NumShuffleVectorInst | 100272 | 100292 | 20 | 0.02% | | instcount.NumSIToFPInst | 29131 | 29113 | -18 | -0.06% | | instcount.NumSRemInst | 1543 | 1543 | 0 | 0.00% | | instcount.NumStoreInst | 805394 | 804351 | -1043 | -0.13% | | instcount.NumSubInst | 61337 | 61414 | 77 | 0.13% | | instcount.NumSwitchInst | 8527 | 8524 | -3 | -0.04% | | instcount.NumTruncInst | 60523 | 60484 | -39 | -0.06% | | instcount.NumUDivInst | 2381 | 2381 | 0 | 0.00% | | instcount.NumUIToFPInst | 5549 | 5549 | 0 | 0.00% | | instcount.NumUnreachableInst | 9855 | 9855 | 0 | 0.00% | | instcount.NumURemInst | 1305 | 1305 | 0 | 0.00% | | instcount.NumXorInst | 10230 | 10081 | -149 | -1.46% | | instcount.NumZExtInst | 60353 | 66840 | 6487 | 10.75% | | instcount.TotalBlocks | 829582 | 829004 | -578 | -0.07% | | instcount.TotalFuncs | 83818 | 83817 | -1 | 0.00% | | instcount.TotalInsts | 7316574 | 7308483 | -8091 | -0.11% | TLDR: we produce -0.11% less instructions, -6.84% less `sext`, +10.75% more `zext`. To be noted, clearly, not all new `zext`'s are produced by this fold. (And now i guess it might have been interesting to measure this for D68103 :S) Reviewers: nikic, spatel, reames, dberlin Reviewed By: nikic Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68654 llvm-svn: 374112
* [CVP][NFC] Revisit sext vs. zext testRoman Lebedev2019-10-081-5/+33
| | | | llvm-svn: 374111
* [clang] Add llvm-ifs in test depsVitaly Buka2019-10-081-0/+1
| | | | llvm-svn: 374110
* Fix `compiler_rt_logbf_test.c` test failure for Builtins-i386-darwin test suite.Dan Liew2019-10-081-3/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: It seems that compiler-rt's implementation and Darwin libm's implementation of `logbf()` differ when given a NaN with raised sign bit. Strangely this behaviour only happens with i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt implementation matched Darwin libm. To workaround this the `compiler_rt_logbf_test.c` has been modified to do a comparison on the `fp_t` type and if that fails check if both values are NaN. If both values are NaN they are equivalent and no error needs to be raised. rdar://problem/55565503 Reviewers: rupprecht, scanon, compnerd, echristo Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D67999 llvm-svn: 374109
* Add test coverage to printing of enums and fix display of unsigned valuesFrederic Riss2019-10-083-35/+66
| | | | | | | | | | | | | | | TestCPP11EnumTypes.py should have covered all our bases when it comes to typed enums, but it missed the regression introduced in r374066. The reason it didn't catch it is somewhat funny: the test was copied over from another test that recompiled a source file with a different base type every time, but neither the test source nor the python code was adapted for testing enums. As a result, this test was just running 8 times the exact same checks on the exact same binary. This commit fixes the coverage and addresses the issue revealed by the new tests. llvm-svn: 374108
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-089-25/+42
| | | | | | | | | | | | | and of vendors, not or. If several vendors are provided in the same vendor context trait, the context shall match only if all vendors are matching, not one of them. This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors, all selectors in the construct, device, and implementation sets of the context selector appear in the corresponding trait set of the OpenMP context. llvm-svn: 374107
* StopInfo/Mach: Use early-exits, reflow messy comments, NFCIVedant Kumar2019-10-082-498/+488
| | | | llvm-svn: 374106
* Try to get ubsan-blacklist-vfs.c pass more on WindowsNico Weber2019-10-081-2/+2
| | | | llvm-svn: 374105
* [Reproducer] Don't isntrument methods that get called from the signal handler.Jonas Devlieghere2019-10-082-5/+6
| | | | | | | | | | | | | | LLDB's signal handlers call SBDebugger methods, which themselves try to be really careful about not doing anything non-signal safe. The Reproducer record macro is not careful though, and does unsafe things which potentially caused LLDB to crash. Given that these methods are not particularly interesting I've swapped the RECORD macros with DUMMY ones, so that we still register the API boundary but don't do anything non-signal safe. Thanks Jim for figuring this one out! llvm-svn: 374104
* Try to get readability-deleted-default.cpp to pass on Windows.Nico Weber2019-10-081-2/+19
| | | | | | | | | | | | | | | In MS compatibility mode, "extern inline void g()" is not a redundant declaration for "inline void g()", because of redeclForcesDefMSVC() (see PR19264, r205485). To fix, run the test with -fms-compatiblity forced on and off and explicit check for the differing behavior for extern inline. Final bit of PR43593. Differential Revision: https://reviews.llvm.org/D68640 llvm-svn: 374103
OpenPOWER on IntegriCloud