CodeGet: Init 32bit pointers with 0xFFFFFFFF

[vitalybuka]

Summary

Patch makes D63967 effective for 32bit platforms and improves pattern
initialization there. It cuts size of 32bit binary compiled with
-ftrivial-auto-var-init=pattern by 2% (3% with -Os).

Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options)

                   master           patch      diff
Os pattern   7.915580e+05    7.698424e+05 -0.028387 
O3 pattern   9.953688e+05    9.752952e+05 -0.019325

Zero vs Pattern on master

               zero       pattern      diff
Os     7.689712e+05  7.915580e+05  0.031380
O3     9.744796e+05  9.953688e+05  0.021133

Zero vs Pattern with the patch

               zero       pattern      diff
Os     7.689712e+05  7.698424e+05  0.000789
O3     9.744796e+05  9.752952e+05  0.000742

[pcc]

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

[jfb]

In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

Indeed.

[vitalybuka]

In D64597#1581654, @jfb wrote:

In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

Indeed.

Done. This is even more effective.
Maybe we should consider 0xAA for floats on 64bit?

[vitalybuka]

0xFFFFFFFF

[vitalybuka]

undo unrelated line

[hubert.reinterpretcast]

In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

[pcc]

In D64597#1582944, @hubert.reinterpretcast wrote:

In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

Right, though if your zero page is mapped then 0xffffffff is probably as good as 0x000000aa.

[jfb]

In D64597#1582944, @hubert.reinterpretcast wrote:

In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

On 32-bit platforms the only region that's likely to trap is the zero page. This seems to be the best choice, but platforms with other regions should be able to tune this value (i.e. I'd accept platform checks here which change the value on such a target).

[hubert.reinterpretcast]

In D64597#1582950, @jfb wrote:

On 32-bit platforms the only region that's likely to trap is the zero page. This seems to be the best choice, but platforms with other regions should be able to tune this value (i.e. I'd accept platform checks here which change the value on such a target).

Sounds good. If I get more information from my internal inquiries, then we'll follow up in a later patch. Thanks.

clang/lib/CodeGen/PatternInit.cpp

 #include "llvm/IR/Type.h"
 
 llvm::Constant *clang::CodeGen::initializationPatternFor(CodeGenModule &CGM,
                                                          llvm::Type *Ty) {
   // The following value is a guaranteed unmappable pointer value and has a
   // repeated byte-pattern which makes it easier to synthesize. We use it for
   // pointers as well as integers so that aggregates are likely to be
   // initialized with this repeated value.
-  constexpr uint64_t LargeValue = 0xAAAAAAAAAAAAAAAAull;
   // For 32-bit platforms it's a bit trickier because, across systems, only the
-  // zero page can reasonably be expected to be unmapped, and even then we need
-  // a very low address. We use a smaller value, and that value sadly doesn't
-  // have a repeated byte-pattern. We don't use it for integers.
-  constexpr uint32_t SmallValue = 0x000000AA;
+  // zero page can reasonably be expected to be unmapped. We use max 0xFFFFFFFF
+  // assuming that memory access will overlap into zero page.
+  const uint64_t IntValue =
+      CGM.getContext().getTargetInfo().getMaxPointerWidth() < 64
+          ? 0xFFFFFFFFFFFFFFFFull
+          : 0xAAAAAAAAAAAAAAAAull;
   // Floating-point values are initialized as NaNs because they propagate. Using
   // a repeated byte pattern means that it will be easier to initialize
   // all-floating-point aggregates and arrays with memset. Further, aggregates
   // which mix integral and a few floats might also initialize with memset
   // followed by a handful of stores for the floats. Using fairly unique NaNs
   // also means they'll be easier to distinguish in a crash.
   constexpr bool NegativeNaN = true;
   constexpr uint64_t NaNPayload = 0xFFFFFFFFFFFFFFFFull;
   if (Ty->isIntOrIntVectorTy()) {
     unsigned BitWidth = cast<llvm::IntegerType>(
                             Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
                             ->getBitWidth();
     if (BitWidth <= 64)
-      return llvm::ConstantInt::get(Ty, LargeValue);
+      return llvm::ConstantInt::get(Ty, IntValue);
     return llvm::ConstantInt::get(
-        Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, LargeValue)));
+        Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, IntValue)));
   }
   if (Ty->isPtrOrPtrVectorTy()) {
     auto *PtrTy = cast<llvm::PointerType>(
         Ty->isVectorTy() ? Ty->getVectorElementType() : Ty);
     unsigned PtrWidth = CGM.getContext().getTargetInfo().getPointerWidth(
         PtrTy->getAddressSpace());
-    llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
-    uint64_t IntValue;
-    switch (PtrWidth) {
-    default:
+    if (PtrWidth > 64)
       llvm_unreachable("pattern initialization of unsupported pointer width");
-    case 64:
-      IntValue = LargeValue;
-      break;
-    case 32:
-      IntValue = SmallValue;
-      break;
-    }
+    llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
     auto *Int = llvm::ConstantInt::get(IntTy, IntValue);
     return llvm::ConstantExpr::getIntToPtr(Int, PtrTy);
   }
   if (Ty->isFPOrFPVectorTy()) {
     unsigned BitWidth = llvm::APFloat::semanticsSizeInBits(
         (Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
             ->getFltSemantics());
     llvm::APInt Payload(64, NaNPayload);

clang/test/CodeGenCXX/auto-var-init.cpp

 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks %s -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK,CHECK-O0
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O0,PATTERN,PATTERN-O0
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -O1 -fno-experimental-new-pass-manager -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O1,PATTERN,PATTERN-O1,PATTERN-O1-LEGACY
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -O1 -fexperimental-new-pass-manager -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O1,PATTERN,PATTERN-O1,PATTERN-O1-NEWPM
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O0,ZERO,ZERO-O0
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -O1 -fno-experimental-new-pass-manager -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O1,ZERO,ZERO-O1,ZERO-O1-LEGACY
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -O1 -fexperimental-new-pass-manager -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O1,ZERO,ZERO-O1,ZERO-O1-NEWPM
 // RUN: %clang_cc1 -std=c++14 -triple i386-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s -check-prefixes=CHECK-O0,PATTERN,PATTERN-O0
 
 #pragma clang diagnostic ignored "-Winaccessible-base"
 
 #ifdef __x86_64__
 char inits[] = {"-86/-21846/-1431655766/i64/-6148914691236517206/-6148914691236517206/i128/-113427455640312821154458202477256070486/i64/-6148914691236517206/AA/"};
 #else
-char inits[] = {"-86/-21846/-1431655766/i32/-1431655766/-6148914691236517206/i32/-1431655766/i32/170/AA/"};
+char inits[] = {"-1/-1/-1/i32/-1/-1/i32/-1/i32/-1/FF/"};
 #define __int128 int;
 #endif
 // PATTERN: @inits = {{.*}} c"[[I8:[^/]+]]/[[I16:[^/]+]]/[[I32:[^/]+]]/[[ILONGT:[^/]+]]/[[ILONG:[^/]+]]/[[I64:[^/]+]]/[[I128T:[^/]+]]/[[I128:[^/]+]]/[[IPTRT:[^/]+]]/[[IPTR:[^/]+]]/[[IC:[^/]+]]/\00", align 1
 
 template<typename T> void used(T &) noexcept;
 
 #define TEST_UNINIT(NAME, TYPE)                 \
   using type_##NAME = TYPE;                     \

 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%custom)
 
 TEST_UNINIT(intptr4, int*[4]);
 // CHECK-LABEL:      @test_intptr4_uninit()
 // CHECK:            %uninit = alloca [4 x i32*], align
 // CHECK-NEXT:       call void @{{.*}}used{{.*}}%uninit)
 // PATTERN-O1-LABEL: @test_intptr4_uninit()
 // PATTERN-O1:       %1 = bitcast [4 x i32*]* %uninit to i8*
-// PATTERN-O1-NEXT:  call void @llvm.memset.p0i8.i64(i8* nonnull align 16 %1, i8 -86, i64 32, i1 false)
+// PATTERN-O1-NEXT:  call void @llvm.memset.p0i8.i64(i8* nonnull align 16 %1, i8 [[I8]], i64 32, i1 false)
 // ZERO-LABEL:       @test_intptr4_uninit()
 // ZERO:             call void @llvm.memset{{.*}}, i8 0,
 
 TEST_BRACES(intptr4, int*[4]);
 // CHECK-LABEL: @test_intptr4_braces()
 // CHECK:       %braces = alloca [4 x i32*], align [[ALIGN:[0-9]*]]
 // CHECK-NEXT:  bitcast
 // CHECK-NEXT:  call void @llvm.memset{{.*}}(i8* align [[ALIGN]] %{{.*}}, i8 0, i64 32, i1 false)