RFR(S): Bugfix: Clear High Word in Integer.bitCount() Intrinsic on SparcV9

[David Chase]

But the scheduling issue does seem a little interesting.
Does the macroassembler deal with that?
I'm just curious, because I am still new to this.

There is also the possibility of a peephole-ish optimization (that can be informed by general flow analysis) that keeps track of zero bits in a word -- for instance, if the source of the data was a LDUW, there's no need to clear the bits.

David

On 2012-12-14, at 12:23 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 12/14/12 8:48 AM, Reingruber, Richard wrote:
>> Thanks, Vladimir and Chris, for your reviews and the bug id.
>> 
>>   > It would seem easier to just write two assembler instructions instead of using expand.
>> 
>> That's what I did first, and it was easier ;)
>> 
>>   > Is there a particular reason you are using expand?
>> 
>> With the expand there is a chance for a better schedule. When testing, I saw for example that the convI2L_reg_zex was scheduled into the delay slot of a predecessor block.
>> 
>> Is there a reason _not_ to use the expand?
> 
> It is harder to understand what instruction does and follow when debugging a problem. Yes, it could be scheduled separately but it hit-and-miss. Also your code uses an additional (long) register which we should avoid. Adding 0xffffff immediate further complicated the code.
> 
> We use expand rules if we need to use the same sequence of few instructions in several mach nodes. Or historically because we used emit_data() complicated encoding before. After we switched to macroassembler instructions we are trying to avoid expand encoding.
> 
> Thanks,
> Vladimir