SPARC: unsigned vs. signed int loads
John Rose
John.Rose at Sun.COM
Wed Feb 18 00:50:09 PST 2009
On Feb 17, 2009, at 11:51 PM, Christian Thalinger wrote:
>> Or more generally, n->bottom_type()->as_int()->_lo >= 0.
>
> Sorry, I don't understand. What does this predicate (or both) check
> for? And where should it be, in loadB or loadUB?
In practice, the only types the LoadB node will have are [-128..127]
and [0..1], in which case bottom_type() == TypeInt::BOOL works just
fine.
But here are some of the interesting details behind that predicate:
A TypeInt (from opto/type.hpp) has _hi and _lo fields, which give the
inclusive bounds to that type.
If TypeInt::_lo >= 0, then the type has no negative values, and hence
does not need sign extension.
If you are loading a byte, you also need to check that TypeInt::_hi <
128.
Finally, the sketch above is incomplete, since the bottom_type in
general will need to be tested whether it is in fact a TypeInt, using
isa_int.
A local subroutine within the AD file could work:
// t is an int type, positive, and fits in the given # of bits without
overflow
static bool is_positive(const Type* t, int bits) {
const TypeInt* ti = t->isa_int();
return ti != NULL && ti->_lo >= 0 && ((-1 << (bits-1)) & ti->_hi)
== 0;
}
If the type of a load matches that predicate, then you know that the
high-order bit is zero, and loadB can be strength-reduced to loadUB.
That's the explanation.
-- John
More information about the hotspot-compiler-dev
mailing list