[LLVMdev] Clang question on x86-64 class type definitions

[Panning, Benjamin J]

Hi All,

I have a question on the type definitions that Clang generates when compiling for x86-64.  Here is the C++ code that I compile:

                class TestClass1 {
                                int X;
                public:
                                virtual int Foo() { return 1; }
                };

                class TestClass2 : public TestClass1 {
                                int X;
                public:
                                virtual int Foo() { return 1; }
                };

                class TestClass3 : public TestClass2 {
                                int X;
                public:
                                virtual int Foo() { return 1; }
                };

Here is the command lines that I am using, for 32-bit and 64-bit mode respectively:

                clang.exe -S -emit-llvm -O0 test.cpp -o test.ll
                clang.exe -S -emit-llvm -O0 test.cpp -o test.ll -march=x86-64

The 32-bit compile produces this, which I understand:

                %class.TestClass3 = type { %class.TestClass2, i32 }
                %class.TestClass2 = type { %class.TestClass1, i32 }
                %class.TestClass1 = type { i32 (...)**, i32 }

The 64-bit compile produces this:

                %class.TestClass3 = type { %class.TestClass2, i32, [4 x i8] }
                %class.TestClass2 = type { [12 x i8], i32 }
                %class.TestClass1 = type { i32 (...)**, i32 }

A few basic questions: (1) Why does TestClass2 have a [12 x i8] array instead of a reference to TestClass1?  (2) What is the [4 x i8] array at the end of TestClass3?  (3) Is it safe to use a bitcast instead of a getelementptr constant expression for casting a TestClass3* to a TestClass1* in this case (I see no other way of doing it...)?

I'm not very knowledgeable about Clang, and I greatly appreciate your help.

Thanks,
Ben



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/4f0df5e9/attachment.html>