Here are some high-level comments. My worry is that it gets too complicated
with
too many different representations.
http://codereview.chromium.org/6881003/diff/4001/src/hydrogen.cc
File src/hydrogen.cc (left):
http://codereview.chromium.org/6881003/diff/4001/src/hydrogen.cc#oldcode1837
src/hydrogen.cc:1837: CompareConversionUses(to_convert->at(index),
Thanks for cleaning this up!
http://codereview.chromium.org/6881003/diff/4001/src/hydrogen.cc
File src/hydrogen.cc (right):
http://codereview.chromium.org/6881003/diff/4001/src/hydrogen.cc#newcode1867
src/hydrogen.cc:1867: HPhase phase("Insert representation changes",
this);
Not sure that the representation computation does the right thing. Why
can you just remove this part?
Maybe we can do something a little simpler without introducing
completely separate representations for ClampedUint8 and TruncatedInt32.
All values for ClampedUint8, int8, int16, int32, uint8 and uint16 can be
precisely represented as our current Representation::Integer32.
How about attaching the additional information to the range-information
and let the HStoreKeyedSpecialized decide whether to generate conversion
code based on the range and the representation of the input value.
This would avoid the complications with having phi-instructions and
phi-uses of even more different representations.
We still have a small problem with Uint32 values since they are outside
the int32 range - but probably we should deal with this one in a
separate change anyway.
http://codereview.chromium.org/6881003/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
