RFR(S): 8212481: PPC64: Enable POWER9 CPU detection

[Doerr, Martin]

Hi Gustavo,

> I agree. So, if you don't mind, to reduce any future rework on that
> I removed the hardcoded L=1 and now it's just a default. I introduced
> l14() function that matches two bits in the proper field as I don't
> see any collision with any other one bit field at the same position
> (bit 14).
I like it, but the default value needs to get specified in the .hpp file.

> Sure. I think that the confusion came from the fact that I split
> the "CPU instruction support" section in two by adding a new one
> called "OS instruction support" when I refactored the TM detection.
> Given a second thought tho I think it's not necessary, so I've put
> has_tm() back to the block as you instructed, adding an empty line
> before has_mtfprd() as it's an alias, and added the "rtm is deter-
> mined by OS" comment were it applies.
Thanks for cleaning it up.

> I just have one question regarding the feature-string. I see
> instrumentation for "fsqrts" feature but it's not currently
> advertised by the feature-string. On the other hand, ISA info
> looks to indicate that fsqrt and fsqrts are not aliases, because:
> 
> fsqrt  P2  -> Instruction introduced in the POWER2 Architecture.
> fsqrts PPC -> Instruction introduced in the PowerPC Architecture prior to ISA v2.00
> 
> so I'm wondering if just for completeness the "fsqrts" feature
> should be included in the feature-string. Besides that I don't
> see instrumentation to support has_mftgpr(), which is commented
> out, thus should we remove it? Like the following:

This code is very old. If we are sure nobody can run the VM on a machine without these instructions they can get removed from the feature checking.
The mftgpr was only designed for an extension of Power6 and the opcode was reused for something else later on if I remember correctly. I think you can remove the remaining comment.

Best regards,
Martin