summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX
Commit message (Collapse)AuthorAgeFilesLines
* Use FinishThunk to finish musttail thunksReid Kleckner2020-04-132-0/+56
| | | | | | | | | | | | | | | | | FinishThunk, and the invariant of setting and then unsetting CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't exist when I added this musttail codepath in ab2090d10765 (2014). Recently in 28328c3771, I started using this codepath on non-Windows platforms, and users reported problems during release testing (PR44987). The issue was already present for users of EH on i686-windows-msvc, so I added a test for that case as well. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D76444 (cherry picked from commit ce5173c0e174870934d1b3a026f631d996136191)
* Fix wrong devirtualization when the final overrider in one base classRichard Smith2020-01-311-0/+43
| | | | | | overrides the final overrider in a different base class. (cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-241-1/+1
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* [DebugInfo] Add option to clang to limit debug info that is emitted for classes.Amy Huang2020-01-141-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds an option to limit debug info by only emitting complete class type information when its constructor is emitted. This applies to classes that have nontrivial user defined constructors. I implemented the option by adding another level to `DebugInfoKind`, and a flag `-flimit-debug-info-constructor`. Total object file size on Windows, compiling with RelWithDebInfo: before: 4,257,448 kb after: 2,104,963 kb And on Linux before: 9,225,140 kb after: 4,387,464 kb According to the Windows clang.pdb files, here is a list of types that are no longer complete with this option enabled: https://reviews.llvm.org/P8182 Reviewers: rnk, dblaikie Subscribers: aprantl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72427
* [ItaniumCXXABI] Make tls wrappers properly comdatMartin Storsjö2020-01-133-7/+8
| | | | | | | | | | | | Just marking a symbol as weak_odr/linkonce_odr isn't enough for actually tolerating multiple copies of it at linking on windows, it has to be made a proper comdat; make it comdat for all platforms for consistency. This should hopefully fix https://bugzilla.mozilla.org/show_bug.cgi?id=1566288. Differential Revision: https://reviews.llvm.org/D71572
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-0/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* Revert "[DWARF5][clang]: Added support for DebugInfo generation for auto ↵Sam McCall2020-01-131-22/+0
| | | | | | | | | return type for C++ member functions." This reverts commit 6d6a4590c5d4c7fc7445d72fe685f966b0a8cafb, which introduces a crash. See https://reviews.llvm.org/D70524 for details.
* [DWARF5][clang]: Added support for DebugInfo generation for auto return type ↵Awanish Pandey2020-01-131-0/+22
| | | | | | | | | | | | | | | | | for C++ member functions. Summary: This patch will provide support for auto return type for the C++ member functions. This patch includes clang side implementation of this feature. Patch by: Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: dblaikie, aprantl, shafik, alok, SouraVX, jini.susan.george Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D70524
* Add support for __declspec(guard(nocf))Andrew Paverd2020-01-101-0/+84
| | | | | | | | | | | | | | | | | | Summary: Avoid using the `nocf_check` attribute with Control Flow Guard. Instead, use a new `"guard_nocf"` function attribute to indicate that checks should not be added on indirect calls within that function. Add support for `__declspec(guard(nocf))` following the same syntax as MSVC. Reviewers: rnk, dmajor, pcc, hans, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, tomrittervg, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72167
* [ItaniumCXXABI] Don't mark an extern_weak init function as dso_local on windowsMartin Storsjö2019-12-231-0/+9
| | | | | | | | | Since 6bf108d77a3c, we try to not mark extern_weak symbols as dso_local, to allow using COFF stubs for references to those symbols (as the symbol may be missing, resolving to an absolute address zero, outside of the current DSO). Differential Revision: https://reviews.llvm.org/D71716
* Change triple in test case to not include triples the test shouldn'tAmy Huang2019-12-181-2/+2
| | | | | pass. This is fixes changes from a85f5efd9597d0036f5c347b362cb873bdf51f16.
* Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr.Amy Huang2019-12-181-0/+18
| | | | | | | | | | | | | | | | | | | | Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
* [c++20] P1959R0: Remove support for std::*_equality.Richard Smith2019-12-162-214/+1
|
* Correct gcc vector splat conversion from float to int-vectorErich Keane2019-12-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | In looking into some other code, I came across this issue where a float converted to a gcc integer vector via a splat causes it to miss the float-to-integral cast, which causes some REALLY strange codegen bugs. The AST looked like: `-ImplicitCastExpr <col:13> 'gcc_int_2':'__attribute__((__vector_size__(2 * sizeof(int)))) int' <VectorSplat> `-ImplicitCastExpr <col:13> 'float' <LValueToRValue> `-DeclRefExpr <col:13> 'float' lvalue ParmVar 0x556f16a5dc90 'f' 'float' Despite the type of the VectorSplat cast as printed, it ended up becoming a vector of float, which caused non-matching instructions. For example, IntVector + a float constant resulted in: add <2 x i32> %8, <2 x float> <float 3.000000e+00, float 3.000000e+00> This patch corrects the conversion so that the float is first converted to an integral, THEN splatted.
* [profile] Fix a crash when -fprofile-remapping-file= triggers an errorFangrui Song2019-12-132-0/+8
| | | | | | Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D71485
* Remove extra character I added to test my changes that I forgot to delete ↵Douglas Yung2019-12-121-1/+1
| | | | before submitting.
* Fix test to work correctly on 32-bit platforms.Douglas Yung2019-12-121-1/+2
|
* [NFC] - Partially revert 9c48c2f9c477007234cGabor Buella2019-12-121-1/+1
|
* [NFC] - Typo fix in test/CodeGenCXX/runtime-dllstorage.cppGabor Buella2019-12-121-5/+5
| | | | | | Reviewed By: Jim Differential Revision: https://reviews.llvm.org/D48921
* Fix detection of __attribute__((may_alias)) to properly look throughRichard Smith2019-12-111-0/+25
| | | | | | | type sugar. We previously missed the attribute in a lot of cases in C++, because there's often other type sugar there (eg, ElaboratedType).
* [Clang] Pragma vectorize_width() implies vectorize(enable)Sjoerd Meijer2019-12-112-7/+59
| | | | | | | | | | | | | | | | | | | | | | Let's try this again; this has been reverted/recommited a few times. Last time this got reverted because for this loop: void a() { #pragma clang loop vectorize(disable) for (;;) ; } vectorisation was incorrectly enabled and the vectorize.enable metadata was set due to a logic error. But with this fixed, we now imply vectorisation when: 1) vectorisation is enabled, which means: VectorizeWidth > 1, 2) and don't want to add it when it is disabled or enabled, otherwise we would be incorrectly setting it or duplicating the metadata, respectively. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D69628
* [c++20] Implement P1185R2 (as modified by P2002R0).Richard Smith2019-12-101-7/+45
| | | | | | For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
* Actually delay processing DelayedDllExportClasses until the outermost class ↵Hans Wennborg2019-12-041-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | is finished (PR40006) This was already the intention of DelayedDllExportClasses, but code such as this would break it: template<typename> struct Tmpl {}; struct Outer { struct Inner { __declspec(dllexport) Inner() = default; unsigned int x = 0; }; Tmpl<Inner> y; }; ActOnFinishCXXNonNestedClass() would get called when the instantiation of Templ<Inner> is finished, even though the compiler is still not finished with Outer, causing the compile fail. This hooks into Sema::{Push,Pop}ParsingClass() to avoid calling ActOnFinishCXXNonNestedClass() for template instantiations while a class is being parsed. Differential revision: https://reviews.llvm.org/D70905
* [Clang] Define Fuchsia C++ABIPetr Hosek2019-12-031-6/+26
| | | | | | | Currently, it is a modified version of the Itanium ABI, with the only change being that constructors and destructors return 'this'. Differential Revision: https://reviews.llvm.org/D70575
* [MS] Emit exported complete/vbase destructorsReid Kleckner2019-12-032-3/+10
| | | | | | | | | | | | | | | Summary: Fixes PR44205 I checked, and deleting destructors are not affected. Reviewers: hans Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70931
* Recommit "[DWARF5]Addition of alignment atrribute in typedef DIE."Sourabh Singh Tomar2019-12-031-0/+14
| | | | | | | | | | | | | | | | This revision is revised to update Go-bindings and Release Notes. The original commit message follows. This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* Revert "Revert "As a follow-up to my initial mail to llvm-dev here's a first ↵Eric Christopher2019-11-268-38/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | pass at the O1 described there."" This reapplies: 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4 Original commit message: As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there. This change doesn't include any change to move from selection dag to fast isel and that will come with other numbers that should help inform that decision. There also haven't been any real debuggability studies with this pipeline yet, this is just the initial start done so that people could see it and we could start tweaking after. Test updates: Outside of the newpm tests most of the updates are coming from either optimization passes not run anymore (and without a compelling argument at the moment) that were largely used for canonicalization in clang. Original post: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410 This reverts commit c9ddb02659e3ece7a0d9d6b4dac7ceea4ae46e6d.
* Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at ↵Muhammad Omair Javaid2019-11-268-35/+38
| | | | | | | | | | | | | | | | | | | | | | | the O1 described there." This reverts commit 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4. This commit introduced 9 new failures on lldb buildbot host at http://lab.llvm.org:8014/builders/lldb-aarch64-ubuntu Following tests were failing: lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq1/TestAmbiguousTailCallSeq1.py lldb-api :: functionalities/tail_call_frames/ambiguous_tail_call_seq2/TestAmbiguousTailCallSeq2.py lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py lldb-api :: functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py lldb-api :: functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410
* [clang][CodeGen] Fix wrong memcpy size of no_unique_address in FieldMemcpyizerSenran Zhang2019-11-251-0/+25
| | | | | | | | | | When generating ctor, FieldMemcpyizer wrongly treated zero-sized class members as what should be copied, and generated wrong memcpy size under some special circumstances. This patch tries to fix it. Reviewed By: MaskRay, rjmccall Differential Revision: https://reviews.llvm.org/D70671
* As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 ↵Eric Christopher2019-11-258-38/+35
| | | | | | | | | | | | | | | | | | | | | described there. This change doesn't include any change to move from selection dag to fast isel and that will come with other numbers that should help inform that decision. There also haven't been any real debuggability studies with this pipeline yet, this is just the initial start done so that people could see it and we could start tweaking after. Test updates: Outside of the newpm tests most of the updates are coming from either optimization passes not run anymore (and without a compelling argument at the moment) that were largely used for canonicalization in clang. Original post: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410
* [CGDebugInfo] Emit subprograms for decls when AT_tail_call is understood ↵Vedant Kumar2019-11-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (reland with fixes) Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` This was reverted in 5b9a072c because it attached declaration subprograms to inlinable builtin calls, which interacted badly with the MergeICmps pass. The fix is to not attach declarations to builtins. rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743
* Revert "[DWARF5]Addition of alignment atrribute in typedef DIE."Sam McCall2019-11-181-14/+0
| | | | | This reverts commit 423f541c1a322963cf482683fe9777ef0692082d, which breaks llvm-c ABI.
* [DWARF5]Addition of alignment atrribute in typedef DIE.Sourabh Singh Tomar2019-11-161-0/+14
| | | | | | | | | | | | This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* Don't add optnone or noinline if the function is already marked asAkira Hatanaka2019-11-151-0/+22
| | | | | | | | | | | | always_inline. The assertion in SetLLVMFunctionAttributesForDefinition used to fail when there was attribute OptimizeNone on the AST function and attribute always_inline on the IR function. This happens because base destructors are annotated with always_inline when the code is compiled with -fapple-kext (see r124757). rdar://problem/57169694
* Revert "re-land [DebugInfo] Add debug location to stubs generated by ↵Alexandre Ganea2019-11-154-60/+15
| | | | | | CGDeclCXX and mark them as artificial" This reverts commit 9c1baa23526c6d7d06eafefbf82d73bfe9bb3aaf.
* re-land [DebugInfo] Add debug location to stubs generated by CGDeclCXX and ↵Alexandre Ganea2019-11-154-15/+60
| | | | | | mark them as artificial Differential Revision: https://reviews.llvm.org/D66328
* AArch64: add arm64_32 support to Clang.Tim Northover2019-11-121-0/+3
|
* Revert a5c8ec4 "[CGDebugInfo] Emit subprograms for decls when AT_tail_call ↵Hans Wennborg2019-11-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | is understood" This caused Chromium builds to fail with "inlinable function call in a function with debug info must have a !dbg location" errors. See https://bugs.chromium.org/p/chromium/issues/detail?id=1022296#c1 for a reproducer. > Currently, clang emits subprograms for declared functions when the > target debugger or DWARF standard is known to support entry values > (DW_OP_entry_value & the GNU equivalent). > > Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU > tail calls. > > Pre-patch debug session with a cross-TU tail call: > > ``` > * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] > frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] > ``` > > Post-patch (note that the tail-calling frame, "helper", is visible): > > ``` > * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] > frame #1: 0x0000000100000f80 main`helper [opt] [artificial] > frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] > ``` > > rdar://46577651 > > Differential Revision: https://reviews.llvm.org/D69743
* [CGDebugInfo] Emit subprograms for decls when AT_tail_call is understoodVedant Kumar2019-11-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743
* [CodeGenCXX][test] Use -fno-experimental-new-pass-manager for ↵Fangrui Song2019-11-021-1/+1
| | | | | | CodeGenCXX/union-tbaa2.cpp after D68593/llvmorg-10-init-8907-gcecc0d27ad5 It fails with -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=0 builds. Temporarily use -fno-experimental-new-pass-manager while we are investigating the root cause.
* [MS] Don't reference deleted copy ctors from catchable typesReid Kleckner2019-10-301-0/+27
| | | | | | | | | | | When throwing objects with deleted copy constructors, the copy ctor field of the catchable type should remain null and the mangle name changes. This already worked in simple cases, but in cases involving non-trivial subobjects, sometimes LookupCopyingConstructor could return a non-null but deleted constructor decl. Skip those and don't reference them. Fixes PR43680
* [MS] Fix constexpr data member pointer conversionsReid Kleckner2019-10-291-0/+27
| | | | | | | | | | | | | | | Constexpr data member conversions work by starting with the class that originally introduced the field, and converting from there to the type that the user desires. Before this change, Clang was using the inheritance model from the final destination class type instead of the model from the class that originally introduced the field. To fix this, find the relevant FieldDecl and take its parent class instead of using the member pointer type the user provided. Indirect field decls require some special handling to find the parent class. Fixes PR43803
* [DWARF5] Added support for deleted C++ special member functions.Adrian Prantl2019-10-291-0/+31
| | | | | | | | | | This patch adds support for deleted C++ special member functions in clang and llvm. Also added Defaulted member encodings for future support for defaulted member functions. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D69215
* Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""Jordan Rupprecht2019-10-242-30/+9
| | | | | | | | | | | | | | This reverts commit 80371c74ae63d2f260bcc75408be9c6f81e38465. Given the following source: ``` void a() { for (;;) ; } ``` It incorrectly enables vectorization (with vector width 1), as well as generating a warning that vectorization could not be performed.
* [AMDGPU] Fix assertion due to initializer listYaxun Liu2019-10-201-15/+30
| | | | | | | | | | | | | Sometimes a global var is replaced by a different llvm value. clang use GetAddrOfGlobalVar to get the original llvm global variable. For most targets, GetAddrOfGlobalVar returns either the llvm global variable or a bitcast of the llvm global variable. However, for AMDGPU target, GetAddrOfGlobalVar returns the addrspace cast or addrspace cast plus bitcast of the llvm global variable. To get the llvm global variable, these casts need to be stripped, otherwise there is assertion. This patch fixes that. Differential Revision: https://reviews.llvm.org/D69129 llvm-svn: 375362
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-191-0/+7
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-191-0/+11
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* DebugInfo: Render the canonical name of a class template specialization, ↵David Blaikie2019-10-181-0/+5
| | | | | | | | even when nested in another class template specialization Differential Revision: https://reviews.llvm.org/D63031 llvm-svn: 375304
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-172-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 375094
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-171-0/+16
| | | | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569 <https://reviews.llvm.org/D41569>. Re-commit fixing failing test. llvm-svn: 375063
OpenPOWER on IntegriCloud