regression for compressed oops that require shift and add

[Deneau, Tom]

All --

I have noticed a regression when I update to the latest default tip.
This is in the area of compressed pointers.  We typically run with different heap sizes which
force different compression schemes.  The failure is in the scheme where the 32-bit compressed pointer
must be multiplied by 8 and then add a base,  we get this for example with a max heap size of 31g.

The problem is that the shift and add must only be applied if the original compressed oop is not 0.

Previous codegen (good):
	ld_global_s32 $s1, [$d1 + 16];
	cvt_u64_u32 $d1, $s1;
	cmp_eq_b1_u64 $c0, $d1, 0x0;
	mad_u64 $d1, $d1, 8, 0x7fb447fff000;     // $d1 = $d1 * 8 + base
	cmov_b64 $d1, $c0, 0x0, $d1;             // conditionally make $d1 0 if it was originally 0

Current codegen (bad);
	ld_global_s32 $s1, [$d1 + 16];
	cvt_u64_u32 $d1, $s1;
	mad_u64 $d1, $d1, 8, 0x7f0137fff000;

The other compression schemes seem to work ok.
I confess I had not merged with default for a few weeks so my previous working version was based on default 8d0242a07f7e.  But I'm not sure where the regression happened in between there.

I guess you would not notice this in your gate unless you ran with a heap size big enough to cause this kind of compression.

-- Tom