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