Split ConstantInteger into ConstantInteger32 and ConstantInteger64.
In many cases, we expect a constant to be 32-bits or less.
This simplifies range checking for x86 memory operand displacements
(can only be 32-bit), or immediates in instructions (also 32-bit),
since we only store 32-bits (so it trivially fits in 32-bits).
Checks for whether a constant fits in 8-bits can be done on the 32-bit value
instead of the 64-bit value.
When TargetLowering sees a 64-bit immediate as an operand on a 64-bit
instruction, it should have split the 64-bit immediate into a 32-bit
loOperand(), and a 32-bit hiOperand(). So what's left for the Emit pass
should be 32-bit constants.
Other places which work with constants:
- intrinsic operands (the ABI only allows i32 params for atomic mem order,
or atomic is lock free byte-size, or the longjmp param).
- addressing mode optimization (gep expansion should be working with
i32 constants).
- insertelement, and extractelement constant indices (bitcode reader
restricts the type of the index to be i32 also).
I guess now you may end up with multiple copies of what may be the
"same" constant (i64 0 vs i32 0).
BUG=none
R=stichnot@chromium.org
Review URL: https://codereview.chromium.org/569033002
diff --git a/src/PNaClTranslator.cpp b/src/PNaClTranslator.cpp
index df2989c..eac0760 100644
--- a/src/PNaClTranslator.cpp
+++ b/src/PNaClTranslator.cpp
@@ -1777,8 +1777,11 @@
if (IntegerType *IType = dyn_cast<IntegerType>(
Context->convertToLLVMType(NextConstantType))) {
APInt Value(IType->getBitWidth(), NaClDecodeSignRotatedValue(Values[0]));
- Ice::Constant *C =
- getContext()->getConstantInt(NextConstantType, Value.getSExtValue());
+ Ice::Constant *C = (NextConstantType == Ice::IceType_i64)
+ ? getContext()->getConstantInt64(
+ NextConstantType, Value.getSExtValue())
+ : getContext()->getConstantInt32(
+ NextConstantType, Value.getSExtValue());
FuncParser->setNextConstantID(C);
return;
}
