• For builtins with matching instruction, use the required ISA/vector version
• For the rest builtins used in altivec.h, use requirements specified by the header
• Keep the feature checks in SemaChecking as-is, since they give user useful message (only available on POWER8 or later CPUs instead of requires isa-v207-instructions to be enabled)
  • lharx and similar instructions exist since ISA v2.06 (Power 7), while SemaChecking.cpp requires ISA v2.07 (Power 8)

Gentle ping

In D143467#4182457, @nemanjai wrote:

Another note regarding the motivating test case:
Use of vector double should require VSX. We don't really seem to have the ability to turn this off early enough to catch this though. It would seem that in the front end, the target features depend on the compilation options and not the function itself.

However, manually adding the required target feature seems a little mistakable, like the one below. I guess we can not get the required feature in the LLVM instruction TDs(if the builtin is mapped to a IR intrinsic and the intrinsic is selected inside the instruction TD) because this is done in CLANG?

Gentle ping... Any comments?

I'd like to abandon this one since frontend change will eliminate this problem.

Ping

In D143198#4171646, @nemanjai wrote:

The PPC changes look fine to me. I believe that the new TOC loads will likely go away with https://reviews.llvm.org/D140381. Is that assumption correct @qiucf?

In D144534#4144155, @arsenm wrote:

I think this is a backwards canonicalization decision and fabs + fcmp will be more broadly understood

Gentle ping...

LGTM, thanks for catching this.

Looks good, thanks

Is this an AIX only restriction or for all DWARF <= 4?

Rebased on D140381

In D108902#3993706, @shchenz wrote:

Thanks for doing this. Could you please show some data about the performance and compile time? Hope they are both good.

Will change to a combine to IS_FPCLASS (based on D140381)

Thanks!

Need rebase after rG64e4d03c681a1c43ec22aee9ce32b784ed5aee9c?

Committed as https://github.com/llvm/llvm-project/commit/5f68c4111ab9c79b902723df3986dd1033813c01

LGTM. Thanks.

Use AutoUpgrade to rename flt.rounds to get.rounding.

Ping

Thanks for the patch! But does libc++ support to be built with -mabi=ieeelongdouble now? (like libstdc++, if it works correctly, it should co-exist and be linked with different long double ABIs)

This patch looks good and llvm.is.fpclass will by default be expanded (except SystemZ which has their own lowering). Is there any blocker for this?

In D139507#3978449, @sepavloff wrote:

Thank you for working on this!

Is there any reason why we should keep the old intrinsic?

It's not easy to give a direct test case to demonstrate effect of tune-cpu. And even so, the case would be volatile. We can adjust features specific to tune-cpu in PPC.td in future patches.

Change error message regarding __float128.

Thanks!

Update test case

I think rG7aa90b21b453d1ca52fdfccfd7e01e61d9e5b1f1 has already done that.

Thanks for the fix! LGTM, sorry for the absense.

In D101605#3748991, @maryammo wrote:

This patch is functionally incorrect

one.c:

#include <stdio.h>
extern double test10(vector int a, vector int b);
int main() {
  double res;
                 //   0           1           2           3
  vector int a = {0x404c38d4, 0x40460e14, 0x404c38d4, 0x7ae147ae};
                 //   4           5           6           7
  vector int b = {0x4027fae1, 0xfdf3b646, 0x47ae147b, 0x40563851};
  res = test10(a, b);
  printf("res: %f\n", res);
  return 0;
}

two.c:

double test10(vector int a, vector int b) {
  //vector int c = __builtin_shufflevector(a, b, 5, 2, 3, 7);
  //                5     2     3     7
  vector int c = { b[1], a[2], a[3], b[3] };
  return ((vector double)c)[0] + 11.0;
}

Expected result:
res: 67.444000

Actual result:
res: -45563434706068069391700044011884519815891525610042006390324289980530809059647691943421443695410413568.000000

So we have decided to revert it.

Merge conditions.

Abandon this since we have rGe2a1f8ec27b88be670cd867c43588f24516d2bbf.