[PATCH] D64119: [PowerPC] Support constraint code "ww"

Jinsong Ji via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 3 20:29:04 PDT 2019


jsji accepted this revision.
jsji added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for investigating GCC behavior.



================
Comment at: clang/lib/Basic/Targets/PPC.h:211
+      case 's': // VSX vector register to hold scalar double data
+      case 'w': // VSX vector register to hold scalar double data
       case 'a': // Any VSX register
----------------
MaskRay wrote:
> jsji wrote:
> > Add some more comments for `w` to distinguish it from `s`?
> > 
> > Do we want to keep compatibility with GCC? 
> > According to https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Machine-Constraints.html#Machine-Constraints, 
> > `ww` is `FP or VSX register to perform float operations under -mvsx or NO_REGS.`, 
> > while `ws` is `VSX vector register to hold scalar double values `. 
> > 
> > So `ww` can use `FP` while `ws` can NOT ?
> I played with "ws" and "ww" but can't find any behavior difference from assembly produced by powerpc64le-linux-gnu-gcc. I'll keep the current form (which is known to make musl fmax/fmaxf build) unless the gcc semantics are clearer.
OK. Thanks. So maybe it is just the misleading doc problem of GCC.


================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:14080
     return std::make_pair(0U, &PPC::VSRCRegClass);
-  } else if (Constraint == "ws" && Subtarget.hasVSX()) {
+  } else if ((Constraint == "ws" || Constraint == "ww") && Subtarget.hasVSX()) {
     if (VT == MVT::f32 && Subtarget.hasP8Vector())
----------------
MaskRay wrote:
> jsji wrote:
> > Should we exclude `FP` for `ws` and return `VFRCRegClass` instead of `VSFRCRegClass` ?
> Can you elaborate on what I should do? I'm not familiar with the register info stuff...
`VSFRC` contains both `F8RC` and `VFRC`. `F8RC` is FP.
So if `ws` can NOT use FP, then we should not use `VSFRC`.

However, if `ws` can use `FP` as well as you found in later GCC experiments, then we don't need to do this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64119/new/

https://reviews.llvm.org/D64119





More information about the llvm-commits mailing list