summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Add back code to implement "frame var -a,-l,-g" filters.Jim Ingham2017-04-184-35/+171
| | | | | | | | | | r285226 dropped the code that did these checks. I am pretty sure that was inadvertent, so I added that back in and added a test for it. <rdar://problem/31661252> llvm-svn: 300564
* Make the test pass on x86_64-win32 target.Haojian Wu2017-04-181-8/+8
| | | | llvm-svn: 300563
* mingw-w64: enable support for __declspec(selectany)Martell Malone2017-04-183-5/+5
| | | | | | | | | | Add selectany as a GCC spelling for mingw-w64 Reviewers: rnk Differential revision: https://reviews.llvm.org/D32083 llvm-svn: 300562
* [DAG] Improve store merge candidate pruning.Nirav Dave2017-04-183-12/+25
| | | | | | | | | | | | | | Remove non-consecutive stores from store merge candidate search as they cannot be merged and will prevent us from finding subsequent mergeable store cases. Reviewers: jyknight, bogner, javed.absar, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32086 llvm-svn: 300561
* [ASTPrinter] Print template parameter lists for out-of-line functionsAlex Lorenz2017-04-182-0/+52
| | | | llvm-svn: 300560
* Add base-index-based store merge testNirav Dave2017-04-181-0/+31
| | | | llvm-svn: 300559
* LoopRerollPass: Prefer Value::hasOneUse() over Value::getNumUses(). NFC.Zvi Rackover2017-04-181-1/+1
| | | | | | getNumUses() can be more expensive as it iterates over all list's elements. llvm-svn: 300558
* [LV] Cache block mask valuesGil Rapaport2017-04-181-7/+17
| | | | | | | | | | | | This patch is part of D28975's breakdown. Add caching for block masks similar to the cache already used for edge masks, replacing generation per user with reusing the first generated value which dominates all uses. Differential Revision: https://reviews.llvm.org/D32054 llvm-svn: 300557
* Add #pragma clang attributeAlex Lorenz2017-04-1840-52/+3075
| | | | | | | | | | | | | | | | | This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
* Driver: Better detection of mingw-gccMartell Malone2017-04-182-11/+14
| | | | | | | | | | | | | Stop blindly searching for "gcc.exe" on windows. Stop assuming "/usr" on unix, fixes cross compiling. Reviewers: mati865, yaron.keren Subscribers: ismail, rnk Differential revision: https://reviews.llvm.org/D15005 llvm-svn: 300555
* [ConstantRange] fix doxygen comment formatting; NFCSanjay Patel2017-04-182-104/+2
| | | | llvm-svn: 300554
* Make globalaa-retained.ll test catching more cases.Nikolai Bozhenov2017-04-181-3/+43
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: * Add checks for store. That is needed because GlobalsAA is called twice in the current pipeline with different sets of Function passes following it. However, the loads are eliminated using instcombine which happens everywhere. On the other hand, DeadStoreElimination is performed only once so by checking for store we'll be able to catch more cases when GlobalsAA is invalidated unintentionally. * Add empty function above/below the test so that we don't depend on the relative order of instcombine/dead-store-elimination and the pass that invalidates the analysis (inside the same FunctionPassManager). Reviewers: kristof.beyls Reviewed By: kristof.beyls Subscribers: llvm-commits, n.bozhenov Differential Revision: https://reviews.llvm.org/D32015 Patch by Andrei Elovikov <andrei.elovikov@intel.com> llvm-svn: 300553
* [GVNHoist] Mark GlobalsAA as preserved by GVNHoist.Nikolai Bozhenov2017-04-181-0/+3
| | | | | | | | | | | | | Reviewers: sebpop, hiraditya Reviewed By: sebpop Subscribers: n.bozhenov, llvm-commits Differential Revision: https://reviews.llvm.org/D32158 Patch by Andrei Elovikov <andrei.elovikov@intel.com> llvm-svn: 300552
* Add store Merge test.Nirav Dave2017-04-181-0/+25
| | | | llvm-svn: 300551
* [ARM] Add hardware build attributes in assemblerOliver Stannard2017-04-183-0/+35
| | | | | | | | | | | | | | | | | This passes an option to the ARM assembly parser to emit build attributes for the hardware selected by command line options, when assembling an assembly file. This is not enabled for C/C++, as this would result in duplicate build attribute directives being emitted in each inline assembly block, when emitting assembly. This also adds an option to allow disabling this behaviour for assembly files, for users who were relying on the old behaviour. Differential revision: https://reviews.llvm.org/D31813 llvm-svn: 300550
* [ARM,AArch64] Define __ELF__ for arm-none-eabihf and AArch64Oliver Stannard2017-04-182-1/+11
| | | | | | | This macro is defined for arm-none-eabi as of r266625, but it should also be defined for eabihf and aarch64. llvm-svn: 300549
* Introduce FPR and Debug Registers/NetBSD/amd64 supportKamil Rytarowski2017-04-188-39/+678
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This code offers Debug Registers (80386) model in LLDB/amd64. This is initial support and has one issue that will be addressed later, Debug Register trap (TRAP_DBREG) is registered as (TRAP_TRACE) for unknown reason. On the other hand this works good enough to move on and leave this bug to be squashed later. Improve the NativeProcessNetBSD::ReinitializeThreads() function, stop setting inside it SetStoppedByExec(). This fixes incorrect stop reason on attaching (SetStoppedBySignal(SIGSTOP)). This commits also has no functional style improvements from clang-format. This code also ships with FXSAVE support on NetBSD. Demo: ``` $ lldb ./watch (lldb) target create "./watch" Current executable set to './watch' (x86_64). (lldb) b main Breakpoint 1: where = watch`main + 15 at watch.c:8, address = 0x000000000040087f (lldb) r Process 1573 launched: './watch' (x86_64) Process 1573 stopped * thread #1, stop reason = breakpoint 1.1 frame #0: 0x000000000040087f watch`main(argc=1, argv=0x00007f7fffa12b88) at watch.c:8 5 { 6 int i, j, k; 7 -> 8 for (i = 0; i < 3; i++) 9 for (j = 0; j < 3; j++) 10 for (k = 0; k < 3; k++) 11 printf("Hello world! i=%d j=%d k=%d\n", i, j, k); (lldb) watch set var i Watchpoint created: Watchpoint 1: addr = 0x7f7fffa12b4c size = 4 state = enabled type = w declare @ '/public/lldb_devel/watch.c:6' watchpoint spec = 'i' new value: 0 (lldb) c Process 1573 resuming Hello world! i=0 j=0 k=0 Hello world! i=0 j=0 k=1 Hello world! i=0 j=0 k=2 Hello world! i=0 j=1 k=0 Hello world! i=0 j=1 k=1 Hello world! i=0 j=1 k=2 Hello world! i=0 j=2 k=0 Hello world! i=0 j=2 k=1 Hello world! i=0 j=2 k=2 Process 1573 stopped * thread #1, stop reason = trace frame #0: 0x00000000004008cc watch`main(argc=1, argv=0x00007f7fffa12b88) at watch.c:8 5 { 6 int i, j, k; 7 -> 8 for (i = 0; i < 3; i++) 9 for (j = 0; j < 3; j++) 10 for (k = 0; k < 3; k++) 11 printf("Hello world! i=%d j=%d k=%d\n", i, j, k) ``` FPR (in another program using libm) ``` (lldb) register read --all General Purpose Registers: rax = 0x000000000000001c rbx = 0x00007f7fff1d4fe0 rcx = 0x000000000000000c rdx = 0x0000000000000002 rdi = 0x0000746711d5b018 __sF + 152 rsi = 0x0000000000000001 rbp = 0x00007f7fff1d3d80 rsp = 0x00007f7fff1d3d60 r8 = 0x00007f7fff1d3470 r9 = 0x0000000000000000 r10 = 0x0000000000000001 r11 = 0x0000000000000202 r12 = 0x00007f7fff1d3da0 r13 = 0x00007d8ad2d88500 r14 = 0x0000000000000002 r15 = 0x00007f7fffa627e0 rip = 0x00000000004009e9 fpr`main + 217 at fpr.c:15 rflags = 0x0000000000000202 cs = 0x0000000000000047 fs = 0x0000000000000000 gs = 0x0000000000000000 ss = 0x000000000000003f ds = 0x000000000000003f es = 0x000000000000003f eax = 0x0000001c ebx = 0xff1d4fe0 ecx = 0x0000000c edx = 0x00000002 edi = 0x11d5b018 esi = 0x00000001 ebp = 0xff1d3d80 esp = 0xff1d3d60 r8d = 0xff1d3470 r9d = 0x00000000 r10d = 0x00000001 r11d = 0x00000202 r12d = 0xff1d3da0 r13d = 0xd2d88500 r14d = 0x00000002 r15d = 0xffa627e0 ax = 0x001c bx = 0x4fe0 cx = 0x000c dx = 0x0002 di = 0xb018 si = 0x0001 bp = 0x3d80 sp = 0x3d60 r8w = 0x3470 r9w = 0x0000 r10w = 0x0001 r11w = 0x0202 r12w = 0x3da0 r13w = 0x8500 r14w = 0x0002 r15w = 0x27e0 ah = 0x00 bh = 0x4f ch = 0x00 dh = 0x00 al = 0x1c bl = 0xe0 cl = 0x0c dl = 0x02 dil = 0x18 sil = 0x01 bpl = 0x80 spl = 0x60 r8l = 0x70 r9l = 0x00 r10l = 0x01 r11l = 0x02 r12l = 0xa0 r13l = 0x00 r14l = 0x02 r15l = 0xe0 unknown: fctrl = 0x037f fstat = 0x0220 ftag = 0x00 fop = 0x0000 fiseg = 0x11e1a52c fioff = 0x11e1a52c foseg = 0xff1d3d54 fooff = 0xff1d3d54 mxcsr = 0x00001fa0 mxcsrmask = 0x0000ffff st0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} st7 = {0xa5 0xdb 0x2d 0xbd 0x93 0xae 0xb9 0xfe 0xfe 0x3f} mm0 = 0x3fe9d13800000000 mm1 = 0x3e0485fcce89c000 mm2 = 0x3fefd735e0000000 mm3 = 0x0000000000000000 mm4 = 0x3fe0000000000000 mm5 = 0x3fe00000005217f3 mm6 = 0x0000000000000000 mm7 = 0x3fefd735e0000000 xmm0 = {0x00 0x00 0x00 0x00 0x38 0xd1 0xe9 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm1 = {0x00 0xc0 0x89 0xce 0xfc 0x85 0x04 0x3e 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm2 = {0x00 0x00 0x00 0xe0 0x35 0xd7 0xef 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0xe0 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm5 = {0xf3 0x17 0x52 0x00 0x00 0x00 0xe0 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm7 = {0x00 0x00 0x00 0xe0 0x35 0xd7 0xef 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm8 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm9 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} xmm15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00} dr0 = 0x0000000000000000 dr1 = 0x0000000000000000 dr2 = 0x0000000000000000 dr3 = 0x0000000000000000 dr4 = 0x0000000000000000 dr5 = 0x0000000000000000 dr6 = 0x00000000ffff0ff0 dr7 = 0x0000000000000400 22 registers were unavailable. ``` Sponsored by <The NetBSD Foundation> Reviewers: labath, emaste, joerg, kettenis Reviewed By: labath Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D32080 llvm-svn: 300548
* [ARM] Add hardware build attributes in assemblerOliver Stannard2017-04-187-398/+464
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the assembler, we should emit build attributes based on the target selected with command-line options. This matches the GNU assembler's behaviour. We only do this for build attributes which describe the hardware that is expected to be available, not the ones that describe ABI compatibility. This is done by moving some of the attribute emission code to ARMTargetStreamer, so that it can be shared between the assembly and code-generation code paths. Since the assembler only creates a MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to check raw features, and not use the convenience functions in ARMSubtarget. If different attributes are later specified using the .eabi_attribute directive, then they will take precedence, as happens when the same .eabi_attribute is specified twice. This must be enabled by an option, because we don't want to do this when parsing inline assembly. The attributes would match the ones emitted at the start of the file, so wouldn't actually change the emitted object file, but the extra directives would be added to every inline assembly block when emitting assembly, which we'd like to avoid. The majority of the changes in the build-attributes.ll test are just re-ordering the directives, because the hardware attributes are now emitted before the ABI ones. However, I did fix one bug which I spotted: Tag_CPU_arch_profile was not being emitted for v6M. Differential revision: https://reviews.llvm.org/D31812 llvm-svn: 300547
* [ARM] GlobalISel: Add support for G_SUBDiana Picus2017-04-188-2/+337
| | | | | | | Support G_SUB throughout the GlobalISel pipeline. It is exactly the same as G_ADD, nothing fancy. llvm-svn: 300546
* clang-tools-extra/test/clang-tidy/performance-inefficient-vector-operation.c ↵NAKAMURA Takumi2017-04-181-1/+2
| | | | | | | pp: Appease targeting msvc with -fno-ms-extensions. FIXME: This may work with -target x86_64-win32. llvm-svn: 300545
* [SampleProfile] Don't assert when printing the DebugLoc of a branch. NFC.Andrea Di Biagio2017-04-181-2/+4
| | | | llvm-svn: 300544
* Revert r300539 - Add #pragma clang attributeAlex Lorenz2017-04-1840-3076/+52
| | | | | | | Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
* Fix one more 'not all control paths return a value' MSVC warningAlex Lorenz2017-04-182-1/+3
| | | | | | The warning was caused by r300539. llvm-svn: 300542
* [SampleProfile] Skip intrinsic calls when visiting callsites in ↵Andrea Di Biagio2017-04-181-1/+1
| | | | | | | | | | | | | | InlineHotFunctions. Before this patch, we always called method 'findCalleeFunctionSamples()' on intrinsic calls. However, intrinsic calls like llvm.dbg.value() are not viable candidates for obvious reasons. No functional change intended. Differential Revision: https://reviews.llvm.org/D32008 llvm-svn: 300541
* [TableGen] Fix MSVC warning that occurs in TableGen generated functionAlex Lorenz2017-04-181-1/+3
| | | | | | This should fix the Windows buildbot failure that happened after r300539. llvm-svn: 300540
* Add #pragma clang attributeAlex Lorenz2017-04-1840-52/+3072
| | | | | | | | | | | | | | The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300539
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-187-213/+69
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* Fix gcc build after r300535.Kristof Beyls2017-04-181-8/+8
| | | | llvm-svn: 300537
* [ARM] Check for correct HW div when lowering divmodDiana Picus2017-04-182-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For subtargets that use the custom lowering for divmod, e.g. gnueabi, we used to check if the subtarget has hardware divide and then lower to a div-mul-sub sequence if true, or to a libcall if false. However, judging by the usage of hasDivide vs hasDivideInARMMode, it seems that hasDivide only refers to Thumb. For instance, in the ARMTargetLowering constructor, the code that specifies whether to use libcalls for (S|U)DIV looks like this: bool hasDivide = Subtarget->isThumb() ? Subtarget->hasDivide() : Subtarget->hasDivideInARMMode(); In the case of divmod for arm-gnueabi, using only hasDivide() to determine what to do means that instead of lowering to __aeabi_idivmod to get the remainder, we lower to div-mul-sub and then further lower the div to __aeabi_idiv. Even worse, if we have hardware divide in ARM but not in Thumb, we generate a libcall instead of using it (this is not an issue in practice since AFAICT none of the cores that we support have hardware divide in ARM but not Thumb). This patch fixes the code dealing with custom lowering to take into account the mode (Thumb or ARM) when deciding whether or not hardware division is available. Differential Revision: https://reviews.llvm.org/D32005 llvm-svn: 300536
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-187-69/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* [clang-tidy] Add a clang-tidy check for possible inefficient vector operationsHaojian Wu2017-04-188-1/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The "performance-inefficient-vector-operation" check finds vector oprations in for-loop statements which may cause multiple memory reallocations. This is the first version, only detects typical for-loop: ``` std::vector<int> v; for (int i = 0; i < n; ++i) { v.push_back(i); } // or for (int i = 0; i < v2.size(); ++i) { v.push_back(v2[i]); } ``` We can extend it to handle more cases like for-range loop in the future. Reviewers: alexfh, aaron.ballman Reviewed By: aaron.ballman Subscribers: zaks.anna, Eugene.Zelenko, mgorny, cfe-commits, djasper Differential Revision: https://reviews.llvm.org/D31757 llvm-svn: 300534
* Emit benchmark tests into the benchmarks build directory, not lib/Eric Fiselier2017-04-181-1/+3
| | | | llvm-svn: 300533
* test commitLeslie Zhai2017-04-181-0/+1
| | | | llvm-svn: 300532
* [sanitizer] Don't include <linux/user.h> in ↵Maxim Ostapenko2017-04-181-10/+6
| | | | | | | | | | | | | | | | | | | | | | | sanitizer_stoptheworld_linux_libcdep.cc on ARM Android Turned out that adding defined(_arm_) in sanitizer_stoptheworld_linux_libcdep.cc breaks android arm with some toolchains. .../llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:36:11: fatal error: 'linux/user.h' file not found # include <linux/user.h> // for pt_regs ^ 1 error generated. Context: #if SANITIZER_ANDROID && defined(__arm__) # include <linux/user.h> // for pt_regs #else This patch removes corresponding #if SANITIZER_ANDROID && defined(__arm__) and a bit rearranges adjacent сode. Differential Revision: https://reviews.llvm.org/D32128 llvm-svn: 300531
* Update google benchmarkEric Fiselier2017-04-1841-159/+1227
| | | | llvm-svn: 300530
* Assert that a valid operator new/delete signature is always found by the ↵Eric Fiselier2017-04-181-4/+3
| | | | | | coroutine body llvm-svn: 300529
* Speculatively attempt to fix bot failures caused by recent coroutine changes.Eric Fiselier2017-04-181-3/+6
| | | | llvm-svn: 300528
* [APInt] Cleanup the reverseBits slow case a little.Craig Topper2017-04-181-6/+4
| | | | | | Use lshrInPlace. Use single bit extract and operator|=(uint64_t) to avoid a few temporary APInts. llvm-svn: 300527
* [APInt] Make operator<<= shift in place. Improve the implementation of ↵Craig Topper2017-04-183-92/+74
| | | | | | tcShiftLeft and use it to implement operator<<=. llvm-svn: 300526
* [XRay][compiler-rt] Use emulated TSC when CPU supports rdtscp, but cannot ↵Douglas Yung2017-04-183-6/+23
| | | | | | | | | | | | | | | | | | | | | determine the CPU frequency A problem arises if a machine supports the rdtscp instruction, but the processor frequency cannot be determined by the function getTSCFrequency(). In this case, we want to use the emulated TSC instead. This patch implements that by adding a call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only returns true if both the processor supports rdtscp and the CPU frequency can be determined. This should fix PR32620. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32067 llvm-svn: 300525
* [coroutines] Fix building of new/delete expressions when ↵Eric Fiselier2017-04-184-12/+152
| | | | | | | | | | | | | | | | | | | | | | get_return_object_on_allocation_failure() is present. Summary: This patch implements [dcl.fct.def.coroutine]p8: > The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of > class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a > global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used. > [...] > The allocation function used in this case must have a non-throwing noexcept-specification. Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31562 llvm-svn: 300524
* Debug Info: Remove special-casing of indirect function argument handling.Adrian Prantl2017-04-184-33/+15
| | | | | | | | | | | | LLVM has changed the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. https://bugs.llvm.org/show_bug.cgi?id=32382 rdar://problem/31205000 llvm-svn: 300523
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-1837-178/+381
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* [asan] Fixup for r300483 (which is a fixup for r300473).Evgeniy Stepanov2017-04-181-4/+5
| | | | | | Sanitizer Printf() does not know about %lu. llvm-svn: 300521
* Add const to a const method. NFCGeorge Burgess IV2017-04-182-2/+2
| | | | llvm-svn: 300520
* TestStaticVariables still fails on Linux.Jim Ingham2017-04-181-0/+2
| | | | llvm-svn: 300519
* [Target] Use hasOneUse() instead of getNumUses().Davide Italiano2017-04-181-1/+1
| | | | | | | The latter does a liner scan over a linked list, therefore is much more expensive. llvm-svn: 300518
* This test is succeeding on macOS with clang.Jim Ingham2017-04-181-6/+1
| | | | llvm-svn: 300517
* Allow a standard library to implement conditional noexcept for optional and ↵Billy Robert O'Neal III2017-04-182-6/+14
| | | | | | | | | | unique_ptr hash functions. These tests were unconditionally asserting that optional and unique_ptr declare throwing hashes, but MSVC++ implements conditional noexcept forwarding that of the underlying hash function. As a result we were failing these tests but there's nothing forbidding strengthening noexcept in that way. Changed the ASSERT_NOT_NOEXCEPT asserts to use types which themselves have non-noexcept hash functions. llvm-svn: 300516
* Fix mishandling of escaped newlines followed by newlines or nuls.Richard Smith2017-04-174-19/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if an escaped newline was followed by a newline or a nul, we'd lex the escaped newline as a bogus space character. This led to a bunch of different broken corner cases: For the pattern "\\\n\0#", we would then have a (horizontal) space whose spelling ends in a newline, and would decide that the '#' is at the start of a line, and incorrectly start preprocessing a directive in the middle of a logical source line. If we were already in the middle of a directive, this would result in our attempting to process multiple directives at the same time! This resulted in crashes, asserts, and hangs on invalid input, as discovered by fuzz-testing. For the pattern "\\\n" at EOF (with an implicit following nul byte), we would produce a bogus trailing space character with spelling "\\\n". This was mostly harmless, but would lead to clang-format getting confused and misformatting in rare cases. We now produce a trailing EOF token with spelling "\\\n", consistent with our handling for other similar cases -- an escaped newline is always part of the token containing the next character, if any. For the pattern "\\\n\n", this was somewhat more benign, but would produce an extraneous whitespace token to clients who care about preserving whitespace. However, it turns out that our lexing for line comments was relying on this bug due to an off-by-one error in its computation of the end of the comment, on the slow path where the comment might contain escaped newlines. llvm-svn: 300515
OpenPOWER on IntegriCloud