[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF
Vitaly Buka via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 12 10:21:58 PDT 2019
This revision was automatically updated to reflect the committed changes.
Closed by commit rL365921: CodeGet: Init 32bit pointers with 0xFFFFFFFF (authored by vitalybuka, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D64597?vs=209401&id=209522#toc
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64597/new/
https://reviews.llvm.org/D64597
Files:
cfe/trunk/lib/CodeGen/PatternInit.cpp
cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
Index: cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
===================================================================
--- cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
+++ cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
@@ -12,7 +12,7 @@
#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
Index: cfe/trunk/lib/CodeGen/PatternInit.cpp
===================================================================
--- cfe/trunk/lib/CodeGen/PatternInit.cpp
+++ cfe/trunk/lib/CodeGen/PatternInit.cpp
@@ -17,12 +17,13 @@
// 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
@@ -36,27 +37,18 @@
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);
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D64597.209522.patch
Type: text/x-patch
Size: 3491 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190712/9024b721/attachment.bin>
More information about the cfe-commits
mailing list