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

[Andrew Haley]

On 22/06/15 17:14, Andrew Dinn wrote:
> On 22/06/15 17:01, Andrew Haley wrote:
>> On 06/22/2015 04:50 PM, Andrew Dinn wrote:
>>> 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?
> 
> I agree it will not necessarily be easy to spot. Bit we know exactly
> where to look (see below).
> 
>>> 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.
> 
> No, that last statement is not at all correct. l2i is explicitly
> inserted into the ideal graph when the compiler knows that a value
> generated as long is being consumed as an int and so needs to be
> truncated.

I'm sure that's true, but it's not really relevant to what I said.

> We also need to be sure that anything spilled as a 32 bit int is
> restored as a 32 bit int with the top bits correspondingly zeroed.

That too.  But C2 has to interact with C1, the interpreter, and all
the stubs, and all the intrinsics.

>> 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.
> 
> Well, you might not want to take this risk and instead add an explicit
> zero of the upper half. But I think we need to be clear what risk we are
> taking.

It's this: if we don't explicitly zero the upper half we'll have to
audit all the code which might present a sign-extended value (instead
of a zero-extended one) in a register that's supposed to contain a
jint.

Andrew.