[aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 (original) (raw)

Andrew Dinn adinn at redhat.com
Mon Jun 22 16:14:18 UTC 2015

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

More information about the hotspot-dev mailing list