[aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2

[Andrew Haley]

On 06/22/2015 04:50 PM, Andrew Dinn wrote:
> On 22/06/15 16:41, Andrew Haley wrote:
>> On 06/22/2015 04:29 PM, Andrew Dinn wrote:
>>> So, it seems Ed is right to use iRegI and rely on an l2i conversion to
>>> zero the top word if the incoming value is long.
>>
>> I don't think that's safe.  I certainly don't think it's a good
>> tradeoff.  I think it'd be the only place in our entire code base
>> where we assume that the high bits of a jint are zero.  If it really
>> wants zeros in the top bits we'd better put them there.
> 
> Well, yes, but it really /ought/ to be safe.
> 
> Whenever we generate an iRegI dst output we should be using a foow
> instruction and end up with the top 32 bits zero. So, wherever we
> consume an iRegI src input we ought to be able to rely on it having top
> bits zero. Either it was generated directly as an iRegI output or it was
> generated as an iRegL output and passed in via an l2i conversion.
> 
> If that assumption fails anywhere then it will only fail because we used
> a foo insn where we really needed a foow. I think we would be better to
> let any such errors fail as quickly as possible, find the error and fix
> the offending code to use foow.

And how would we even notice it, yet alone find the error?

> Your mileage may vary.

Hmm.  So far we've been very conservative, making sure that we always
use the correct mode for inputs and the correct mode for outputs.  If
we're going to start making assumptions that top bits of int ops are
always zero we could always elide l2i to a no-op.  So far we have
resisted that, and with good reason IMO.

I wrote the deoptimization code and was pretty careful to do the right
thing, but also very reassured that it probably didn't matter.  I
don't think we can guarantee that nowhere do we have a sign extension
where there should be a zero extension.

Andrew.