regression for compressed oops that require shift and add

[Doug Simon]

The code appears to be correct for the AMD64 backend (i.e. UncompressPointer.emitCode()). But the HSAIL backend code looks plausibly correct as well. Do you know where the wrong code path is taken in the HSAIL backend while emitting code?

-Doug

On May 30, 2014, at 10:30 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> 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
>