Chromium Code Reviews Chromium Code Reviews
Issue
569033002:
Split ConstantInteger into ConstantInteger32 and ConstantInteger64. (Closed)
DescriptionSplit 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
Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=bc004630f011e69deeca08428e59e15a4a602c1e
Patch Set 1 #Patch Set 2 : format #Patch Set 3 : check for overflow, now that constants are i32 #Patch Set 4 : test min #Patch Set 5 : fix neg overflow check, double checked with ubsan #Patch Set 6 : rebase #Patch Set 7 : format #Patch Set 8 : rebase #
Messages
Total messages: 4 (1 generated)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
