Use ARM-style representation for C++ method pointers under PNaCl/Emscripten

Before this change, Clang uses the x86 representation for C++ method
pointers when generating code for PNaCl.  However, the resulting code
will assume that function pointers are 0 mod 2.  This assumption is
not safe for PNaCl, where function pointers could have any value
(especially in future sandboxing models).

So, switch to using the ARM representation for PNaCl code, which makes
no assumptions about the alignment of function pointers.

Since we're changing the "le32" target, this change also applies to
Emscripten.  The change is beneficial for Emscripten too.  Emscripten
has a workaround to make function pointers 0 mod 2.  This change would
allow the workaround to be removed.

See: https://code.google.com/p/nativeclient/issues/detail?id=3450
llvm-svn: 187051

1 files changed, 14 insertions, 0 deletions

diff --git a/clang/test/CodeGenCXX/static-init-pnacl.cpp b/clang/test/CodeGenCXX/static-init-pnacl.cpp
new file mode 100644
index 00000000000..65844e5d34a
--- /dev/null
+++ b/clang/test/CodeGenCXX/static-init-pnacl.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -emit-llvm -triple=le32-unknown-nacl -o - %s | FileCheck %s
+
+int f();
+
+// Test that PNaCl uses the Itanium/x86 ABI in which the static
+// variable's guard variable is tested via "load i8 and compare with
+// zero" rather than the ARM ABI which uses "load i32 and test the
+// bottom bit".
+void g() {
+  static int a = f();
+}
+// CHECK: load atomic i8* bitcast (i64* @_ZGVZ1gvE1a to i8*) acquire
+// CHECK-NEXT: %guard.uninitialized = icmp eq i8 %0, 0
+// CHECK-NEXT: br i1 %guard.uninitialized, label %init.check, label %init.end