maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/vtable-align.cpp

15 lines
889 B
C++
Raw Normal View History

CodeGen: Use a fixed alignment for vtables. Pointer-sized alignment is sufficient as we only ever read single values from the table. Otherwise we'd bump the alignment to 16 bytes in the backend if the vtable is larger than 16 bytes. This is great for structures that are accessed with vector instructions or copied around, but that's simply not the case for vtables. Shrinks the data segment of a Release x86_64 clang by 0.3%. The wins are larger for i386 and code bases that use vtables more often than we do. This matches the behavior of GCC 5. llvm-svn: 217495
2014-09-10 20:50:59 +08:00
// RUN: %clang_cc1 %s -triple=i386-apple-darwin10 -emit-llvm -o - | FileCheck %s -check-prefix=CHECK-32
// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck %s -check-prefix=CHECK-64
struct A {
virtual void f();
virtual void g();
virtual void h();
};
void A::f() {}
CodeGen: New vtable group representation: struct of vtable arrays. In a future change, this representation will allow us to use the new inrange annotation on getelementptr to allow the optimizer to split vtable groups. Differential Revision: https://reviews.llvm.org/D22296 llvm-svn: 289584
2016-12-14 04:40:39 +08:00
// CHECK-32: @_ZTV1A = unnamed_addr constant { [5 x i8*] } { [5 x i8*] [i8* null, i8* bitcast ({ i8*, i8* }* @_ZTI1A to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1fEv to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1gEv to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1hEv to i8*)] }, align 4
CodeGen: Use a fixed alignment for vtables. Pointer-sized alignment is sufficient as we only ever read single values from the table. Otherwise we'd bump the alignment to 16 bytes in the backend if the vtable is larger than 16 bytes. This is great for structures that are accessed with vector instructions or copied around, but that's simply not the case for vtables. Shrinks the data segment of a Release x86_64 clang by 0.3%. The wins are larger for i386 and code bases that use vtables more often than we do. This matches the behavior of GCC 5. llvm-svn: 217495
2014-09-10 20:50:59 +08:00
CodeGen: New vtable group representation: struct of vtable arrays. In a future change, this representation will allow us to use the new inrange annotation on getelementptr to allow the optimizer to split vtable groups. Differential Revision: https://reviews.llvm.org/D22296 llvm-svn: 289584
2016-12-14 04:40:39 +08:00
// CHECK-64: @_ZTV1A = unnamed_addr constant { [5 x i8*] } { [5 x i8*] [i8* null, i8* bitcast ({ i8*, i8* }* @_ZTI1A to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1fEv to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1gEv to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A1hEv to i8*)] }, align 8