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
10 files changed
