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

[Andrew Dinn]

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. We have explicitly avoided performing any truncation to
effect that l2i in every rule where we accept an input of iRegIorL2I. In
all such cases we have ensured that the instruction which consumes the
input is a foow not a foo. That's quite checkable by eyeball.

For this one case, we also need to be sure that every instruction which
generates an iRegI output uses a foow instruction which, (according to
the manual) zeroes the top bits. That's also checkable by eyeball.

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.

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

regards,


Andrew Dinn
-----------