Page MenuHomePhabricator

[Power9] Implement new vsx instructions: quad-precision move, fp-arithmetic

Authored by cycheng on Jan 12 2016, 5:28 AM.



This change implements the following vsx instructions:

  • quad-precision move
    1. xscpsgnqp, xsabsqp, xsnegqp, xsnabsqp
  • quad-precision fp-arithmetic
    1. xsaddqp(o) xsdivqp(o) xsmulqp(o) xssqrtqp(o) xssubqp(o)
    2. xsmaddqp(o) xsmsubqp(o) xsnmaddqp(o) xsnmsubqp(o)

22 instructions

Diff Detail

Event Timeline

cycheng updated this revision to Diff 44622.Jan 12 2016, 5:28 AM
cycheng retitled this revision from to [Power9] Implement new vsx instructions: quad-precision move, fp-arithmetic.
cycheng updated this object.
cycheng added reviewers: nemanjai, hfinkel, kbarton, tjablin.
cycheng added a subscriber: llvm-commits.
nemanjai added inline comments.Jan 12 2016, 8:22 AM

Last year, we agreed on a naming convention for instruction forms. Please see lib/Target/PowerPC/README.txt (line 626). We have not gotten around to renaming the old ones, but we can at least stick to this naming convention for new forms.


These are VSX instructions, are they not? Why the VMX register class?
I imagine this is because we have never supported f128 in the VSX registers. However, I don't believe the right course of action is to put these in the VMX registers and thereby be able to allocate only half the registers.
We need to do a bit more to implement support for f128.
I imagine that we can add the type to the VSRC class, but I haven't thought about it much.

Of course, we can simply put in FIXME's to deal with the types later.


Can we use a more descriptive name than X44? That does not seem to suggest anything about its use.


Same as above.


Same comment about the name as above.

nemanjai edited edge metadata.Jan 12 2016, 8:50 AM

Overall, is there a reason for the placement of these new definitions? It seems logical that the new definitions appear at the end of what we have so far (new features at the end of the features already defined, new instructions at the end of the file, etc.).
Of course, if there's a good reason to keep the placement here, so be it. However, we should make sure the placement makes sense.


Almost forgot, I think defining classes such as these is fine, but they should have a "pattern" parameter. We don't have a code-gen pattern now, but once we want to generate these, we will.

hfinkel added inline comments.Jan 12 2016, 5:09 PM

Same here (move this up near the HasP8*).


Please move this up near HasP8* to keep things more-or-less semantically grouped.


Same here (move this up near the hasP8*()).

cycheng marked 7 inline comments as done.Jan 13 2016, 12:09 AM
cycheng added inline comments.

Yes, but according to spec, it seems to be the same VMX registers.

Power ISA 3.0 Vector Registers, p.386:

  • When VSX is implemented, the 32 VRs are mapped to VSRs 32-63
  • All instructions that operate on a VR are redefined to operate on the corresponding VSR.

If we read the instruction pesudo code, e.g. xscpsgnqp VRT,VRA,VRB

src1 = VSR[VRA+32] & 0x8000...
src2 = VSR[VRB+32] & 0x7FFF...
VSR[VRT+32] = src1 | src2

Only half of VSX registers are used, that's why spec only use 5 bits for register encoding.

So that's why I choose 'vrrc'.

cycheng updated this revision to Diff 44714.EditedJan 13 2016, 12:36 AM
cycheng edited edge metadata.


  • Follow naming convention to rename global and local instruction forms
  • Add pattern parameter for local defined instruction forms
  • Move new definitions to the end of file
  • Fix IsP9 position

Unresolved issue:

  • Why the VMX register class? => CY: Please read my reply

Thank you for clarifying the selection of the vrrc register class. I probably should have looked at the ISA doc before asking that - just used to VSX instructions having access to all the VSX registers rather than only the VMX ones. I think your choice of register class is the right way to go.

It's fine! Just feel free to discuss : )
I really appreciate any feedback from all of you.

kbarton added inline comments.Jan 27 2016, 1:14 PM

Why are we creating a P9 feature?
For other processors we have defined a processor model, which is a composition of other features (see P7Model and P8Model).
We need to think very carefully about how we want these models to be composed, and what can be enabled/disabled as a result of that composition (and whether that is useful). I'm not immediately convinced this is the best way to handle it.


I would prefer to track this in a separate file.


Same comment about tracking TODOs

cycheng updated this revision to Diff 46221.Jan 27 2016, 10:01 PM
cycheng marked 3 inline comments as done.
cycheng added inline comments.Jan 27 2016, 10:06 PM

Sorry I updated late. I've corrected it after our meeting, but I didn't upload it immediately.

nemanjai added inline comments.Jan 29 2016, 6:31 AM

PO == Opcode?

cycheng added inline comments.Jan 29 2016, 6:58 AM

Yes! It is used in Power ISA, section 1.6.x

cycheng updated this revision to Diff 46748.Feb 2 2016, 11:36 PM


  • Shorten format name: XForm_RD5_XO5_RS5 -> X_RD5_XO5_RS5
  • Move X_VT5_XO5_VB5 to the beginning of p9 vector instruction section, because it is shared among other new vsx instructions
  • Remove unnecessary comments
nemanjai added inline comments.Feb 29 2016, 5:03 AM

Note: A register class for fp128 needs to be defined or we need to allow that type in vrrc.

I think either is fine since the ABI specifies the same vector registers for passing vectors and fp128 parameters.

cycheng added inline comments.Feb 29 2016, 8:56 PM

If we allow it in vrrc, then I should add 'f128' in "def VRRC", right?

def VRRC : RegisterClass<"PPC", [ **f128**, v16i8,v8i16,v4i32,v2i64,v1i128,v4f32], 128,
kbarton accepted this revision.Mar 24 2016, 12:36 PM
kbarton edited edge metadata.


This revision is now accepted and ready to land.Mar 24 2016, 12:36 PM

Committed r264565

cycheng closed this revision.Mar 31 2016, 5:24 PM