LGTM.

LGTM.

Close this review as a different implementation that uses derived type wrapper approach has been landed.

Landed with commit c09d3c1ead632e39c19a78049f6e663b6dbebc4e

LGTM.

LGTM.

LGTM.

LGTM.

Thanks for keeping the ordering consistent. LGTM now.

Ping. Would the reviewers please review this patch?

LGTM.

In D156243#4557253, @kkwli0 wrote:

LG

Fix the test header to to only dump llvm IR.

To remove the pwr10 check as we plan to do it as target feature checking as in clang.

In D156243#4554766, @tschuett wrote:

No worries. Pick your preference.

Rebase to include the fix of adding llvm_unreachable.

Thanks to @klausler for fixing it!

In D155725#4547578, @vdonaldson wrote:

Builds are failing to compile this code in PPCIntrinsicCall.cpp:

const char *getMmaIrIntrName(MMAOp mmaOp) {
  switch (mmaOp) {
  case MMAOp::AssembleAcc:
    return "llvm.ppc.mma.assemble.acc";
  case MMAOp::AssemblePair:
    return "llvm.ppc.vsx.assemble.pair";
  case MMAOp::DisassembleAcc:
    return "llvm.ppc.mma.disassemble.acc";
  case MMAOp::DisassemblePair:
    return "llvm.ppc.vsx.disassemble.pair";
  }
}

mlir::FunctionType getMmaIrFuncType(mlir::MLIRContext *context, MMAOp mmaOp) {
  switch (mmaOp) {
  case MMAOp::AssembleAcc:
    return genMmaVqFuncType(context, /*Quad*/ 0, /*Pair*/ 0, /*Vector*/ 4);
  case MMAOp::AssemblePair:
    return genMmaVpFuncType(context, /*Quad*/ 0, /*Pair*/ 0, /*Vector*/ 2);
  case MMAOp::DisassembleAcc:
    return genMmaDisassembleFuncType(context, mmaOp);
  case MMAOp::DisassemblePair:
    return genMmaDisassembleFuncType(context, mmaOp);
  }
}

with the message

flang/lib/Optimizer/Builder/PPCIntrinsicCall.cpp:1288:1: error: control reaches end of non-void function [-Werror=return-type]

These two switches probably need an error default.

Fix the build failure due to chang-format checking.

In D155725#4535401, @kkwli0 wrote:

LG

Remove check for mma intrinsics from this patch. It will be added back in with the MMA intrinsic patch.

To address review comments.

In D155725#4533144, @tschuett wrote:

In D155725#4532999, @klausler wrote:

In D155725#4532997, @tschuett wrote:

Could you please get the pwr10 check in before continuing to add more unchecked intrinsics.

Why is this important to you? This is a compiler under active development that is not yet suitable for production use.

The buildbots run the test suite from trunk and no buildbot caught the fact that there are issues trying to run the power10 intrinsics on a power9. There are missing tests and/or checks.

In D155725#4532997, @tschuett wrote:

Could you please get the pwr10 check in before continuing to add more unchecked intrinsics.

It seems the module and the test are missing from the last update. Put them back in after rebase.

Add semantic checking for specific supported cpu. In this case, power10.

In D156243#4532250, @tschuett wrote:

Can you prioritise the checking code? The in-tree flang intrinsics may crash on my fictitious PowerPC Apple and your Power 9.

Add the test cases.

Address review comments to remove unrelated changes.

LGTM.

Fixing a build failure using clang as the build compiler.

Attempt to fix the x64 Window build failure that failed due to linker error as:

Add the MMA intrinsic module and the testing of LLVM IR.

LGTM.

In D155725#4515726, @tschuett wrote:

I wanted to say that I could try to use them on an Apple and the compiler would crash somewhere, see https://reviews.llvm.org/D152131.

In D155725#4515348, @tschuett wrote:

I bet that the mma ops are only available on newer ppc cores and not on the old Apple ones. I could not find a feature check.

LGTM.

The code gen part LGTM.

LGTM.

Sorry that the patch file was accidentally added to the review. This revision is to remove it.

To address review comments. Separating typeCompatible into two Booleans.

LGTM. Thanks!

LGTM. Thanks.

In D146751#4227734, @klausler wrote:

In D146751#4227713, @DanielCChen wrote:

@klausler @jeanPerier We have been looking into the derived type wrapper approach. Besides the question in my response to Peter's comments regarding if the derived types layout is OK to represent those 3 different vector types, I have another question of type compatibility checking.
Consider the following vector code:

module m1
vector(integer) :: v1
end module

module m2
vector(integer) :: v2
end module

I recommend that you define "builtin" derived types in one intrinsic module -- perhaps the same one in which the PPC vector intrinsic procedure interfaces are defined -- and reference those derived type definitions via USE association.

@klausler @jeanPerier We have been looking into the derived type wrapper approach. Besides the question in my response to Peter's comments regarding if the derived types layout is OK to represent those 3 different vector types, I have another question of type compatibility checking.
Consider the following vector code:

Thanks for the quick response!

Thanks for the review and the comments!

In D146751#4219738, @tschuett wrote:

Is this the first of ten vendors types? Do I need a flag to enable the PowerPC vector type or does it also work on other architectures?

Thanks @klausler and @peixin! I will wait a day or so to see if others have any more comments.

Ping: I appreciate it if reviewers can review the change. Thanks to all.

I tried to add “rG LLVM Github Monorepo” in the Repository field before creating the revision, but it disappeared. Does someone know why it happened?

In D139333#3980379, @peixin wrote:

"A function name declared with an asterisk type-param-value shall not be an array, a pointer, elemental, or pure. A function
name declared with an asterisk type-param-value shall not have the RECURSIVE attribute."

This is C723, not C724.

In D139333#3980113, @peixin wrote:

I think you are checking C723, not C724.