[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -2405,6 +2421,11 @@ void LoopAccessInfo::analyzeLoop(AAResults *AA, LoopInfo 
*LI,
 
   // Save 'store' instructions. Abort if other instructions write to 
memory.
   if (I.mayWriteToMemory()) {
+// We can safety handle math functions that have vectorized
+// counterparts and have the memory write-only attribute set.
+if (isMathLibCallMemWriteOnly(TLI, I))

mgabka wrote:

can this change be tested with a loop-access analysis tests using a debug 
output? if yes then it does not have to depend on the TLI mappings for 
modf/modff

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] Fix Veclib flags correctly pass to LTO flags (PR #78749)

[Maciej Gabka via cfe-commits]

@@ -31,3 +31,31 @@
 
 // RUN: %clang -fveclib=Accelerate %s -nodefaultlibs -target 
arm64-apple-ios8.0.0 -### 2>&1 | FileCheck 
--check-prefix=CHECK-LINK-NODEFAULTLIBS %s
 // CHECK-LINK-NODEFAULTLIBS-NOT: "-framework" "Accelerate"
+
+
+/* Verify that the correct vector library is passed to LTO flags. */
+
+
+// RUN: %clang -### -fveclib=none -flto %s -v 2>&1  | FileCheck -check-prefix 
CHECK-LTO-NOLIB %s
+// CHECK-LTO-NOLIB: "-plugin-opt=-vector-library=none"
+
+// RUN: %clang -### -fveclib=Accelerate -flto %s -v 2>&1  | FileCheck 
-check-prefix CHECK-LTO-ACCELERATE %s
+// CHECK-LTO-ACCELERATE: "-plugin-opt=-vector-library=Accelerate"
+
+// RUN: %clang -### -fveclib=LIBMVEC -flto %s -v 2>&1  | FileCheck 
-check-prefix CHECK-LTO-LIBMVEC %s
+// CHECK-LTO-LIBMVEC: "-plugin-opt=-vector-library=LIBMVEC-X86"
+
+// RUN: %clang -### -fveclib=MASSV -flto %s -v 2>&1  | FileCheck -check-prefix 
CHECK-LTO-MASSV %s
+// CHECK-LTO-MASSV: "-plugin-opt=-vector-library=MASSV"
+
+// RUN: not %clang -### -fveclib=SVML -flto %s -v 2>&1  | FileCheck 
-check-prefix CHECK-LTO-SVML %s
+// CHECK-LTO-SVML: "-plugin-opt=-vector-library=SVML"
+
+// RUN: %clang -### -fveclib=SLEEF -flto %s -v 2>&1  | FileCheck -check-prefix 
CHECK-LTO-SLEEF %s
+// CHECK-LTO-SLEEF: "-plugin-opt=-vector-library=sleefgnuabi"
+
+// RUN: %clang -### -fveclib=Darwin_libsystem_m -flto %s -v 2>&1  | FileCheck 
-check-prefix CHECK-LTO-DARWIN %s
+// CHECK-LTO-DARWIN: "-plugin-opt=-vector-library=Darwin_libsystem_m"
+
+// RUN: %clang -### -fveclib=ArmPL -flto %s -v 2>&1  | FileCheck -check-prefix 
CHECK-LTO-ARMPL %s

mgabka wrote:

don't you have to specify here --target=aarch64-none-none ? and similarly 
relevant targets for other veclibs? 

https://github.com/llvm/llvm-project/pull/78749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] Fix Veclib flags correctly pass to LTO flags (PR #78749)

[Maciej Gabka via cfe-commits]

@@ -783,6 +783,28 @@ void tools::addLTOOptions(const ToolChain &ToolChain, 
const ArgList &Args,
  "-generate-arange-section"));
   }
 
+  // Pass vector library arguments to LTO.
+  Arg *ArgVecLib = Args.getLastArg(options::OPT_fveclib);
+  if (ArgVecLib && ArgVecLib->getNumValues() == 1) {
+// Map the vector library names from clang front-end to opt front-end. The
+// values are taken from the TargetLibraryInfo class command line options.
+std::optional OptVal =
+llvm::StringSwitch>(ArgVecLib->getValue())

mgabka wrote:

the TLI belongs to llvm world, while clang driver from what I can see is only 
linked with following llvm components:
set(LLVM_LINK_COMPONENTS
  BinaryFormat
  MC
  Object
  Option
  ProfileData
  Support
  TargetParser
  WindowsDriver
  )
so I don't think it is possible to do it.

Unfortunately at the early stage when the  tools::addLTOOptions function is 
called the CodeGenOptions are not even created, perhaps we could have a 
function defined which does the strings checking in 
include/llvm/Analysis/TargetLibraryInfo.h and include it in  the 
CommonArgs.cpp? a least everything would be in one place? what do you think 
@david-arm ?

https://github.com/llvm/llvm-project/pull/78749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] Fix Veclib flags correctly pass to LTO flags (PR #78749)

[Maciej Gabka via cfe-commits]

@@ -31,3 +31,27 @@
 
 // RUN: %clang -fveclib=Accelerate %s -nodefaultlibs -target 
arm64-apple-ios8.0.0 -### 2>&1 | FileCheck 
--check-prefix=CHECK-LINK-NODEFAULTLIBS %s
 // CHECK-LINK-NODEFAULTLIBS-NOT: "-framework" "Accelerate"
+
+
+/* Verify that the correct vector library is passed to LTO flags. */
+
+// RUN: %clang -### -fveclib=Accelerate -flto %s -v 2>&1 | FileCheck 
-check-prefix CHECK-LTO-ACCELERATE %s

mgabka wrote:

you are missing here target, presumably it should be  -target 
arm64-apple-ios8.0.0 as in the other run lines for "-fveclib=Accelerate", I 
think you need to ensure that each of the RUN lines specifies target

https://github.com/llvm/llvm-project/pull/78749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] Fix Veclib flags correctly pass to LTO flags (PR #78749)

[Maciej Gabka via cfe-commits]

@@ -31,3 +31,21 @@
 
 // RUN: %clang -fveclib=Accelerate %s -nodefaultlibs -target 
arm64-apple-ios8.0.0 -### 2>&1 | FileCheck 
--check-prefix=CHECK-LINK-NODEFAULTLIBS %s
 // CHECK-LINK-NODEFAULTLIBS-NOT: "-framework" "Accelerate"
+
+
+/* Verify that the correct vector library is passed to LTO flags. */
+
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -fveclib=LIBMVEC -flto 
%s -v 2>&1 | FileCheck -check-prefix CHECK-LTO-LIBMVEC %s

mgabka wrote:

I think using -v is not necessary here *(other run lines do not use is in this 
file), and from what I remember it changes a bit how the compiler driver works, 
could you remove it here and in the other run lines?

https://github.com/llvm/llvm-project/pull/78749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] Fix Veclib flags correctly pass to LTO flags (PR #78749)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka approved this pull request.

It LGTM, but probably worth to give some extra time in case anybody else thinks 
differently, it would be really good to have it on LLVM18 as well

https://github.com/llvm/llvm-project/pull/78749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 9272aa9 - [Driver] Do not generate error about unsupported target specific options when there is no compiler jobs

[Maciej Gabka via cfe-commits]

Author: Maciej Gabka
Date: 2023-09-11T14:58:36Z
New Revision: 9272aa9d08cbbf5b8612c264d5d547fdefae26c7

URL: 
https://github.com/llvm/llvm-project/commit/9272aa9d08cbbf5b8612c264d5d547fdefae26c7
DIFF: 
https://github.com/llvm/llvm-project/commit/9272aa9d08cbbf5b8612c264d5d547fdefae26c7.diff

LOG: [Driver] Do not generate error about unsupported target specific options 
when there is no compiler jobs

The upstream commit: https://reviews.llvm.org/D151590
added a new flag to mark target specific compiler options.

The side effect of it was that in cases when -### or -v is used without any
input file, clang started emitting an error.
It happened like that becasue there is no compilation actions created
which could consume/verify these target specific options.

This patch changes that error to a warning about unused option in situations
when there is no actions and still generates error when there are actions.

Fix for https://github.com/llvm/llvm-project/issues/64958

Differential Revision: https://reviews.llvm.org/D159361

Added: 
clang/test/Driver/no-action.c

Modified: 
clang/lib/Driver/Driver.cpp

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index ba723eac2a7ee74..9d30159b4b49cea 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -4953,7 +4953,12 @@ void Driver::BuildJobs(Compilation &C) const {
   // already been warned about.
   if (!IsCLMode() || !A->getOption().matches(options::OPT_UNKNOWN)) {
 if (A->getOption().hasFlag(options::TargetSpecific) &&
-!A->isIgnoredTargetSpecific() && !HasAssembleJob) {
+!A->isIgnoredTargetSpecific() && !HasAssembleJob &&
+// When for example -### or -v is used
+// without a file, target specific options are not
+// consumed/validated.
+// Instead emitting an error emit a warning instead.
+!C.getActions().empty()) {
   Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getSpelling() << getTargetTriple();
 } else {

diff  --git a/clang/test/Driver/no-action.c b/clang/test/Driver/no-action.c
new file mode 100644
index 000..bec5960d02eac08
--- /dev/null
+++ b/clang/test/Driver/no-action.c
@@ -0,0 +1,10 @@
+// RUN: %clang --target=aarch64-none-gnu --verbose -mcpu= -march= 2>&1 | 
FileCheck %s --check-prefix=WARNING
+// RUN: %clang --target=aarch64-none-gnu -### -mcpu= -march= 2>&1 | FileCheck 
%s --check-prefix=WARNING
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu --verbose -mcpu= -march= 2>&1 
| FileCheck %s --check-prefix=WARNING
+// RUN: %clang --target=x86_64-unknown-linux-gnu -### -mcpu= -march= 2>&1 | 
FileCheck %s --check-prefix=WARNING
+
+/// In situation when there is no compilation/linking clang should not emit 
error
+/// about target specific options, but just warn that are not used.
+WARNING: warning: argument unused during compilation
+WARNING: warning: argument unused during compilation



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

[Maciej Gabka via cfe-commits]

@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 %s -triple armv7 -fsyntax-only -verify
-// RUN: %clang_cc1 %s -triple aarch64 -fsyntax-only -verify
-// RUN: %clang_cc1 %s -triple aarch64 -target-feature -fp-armv8 -target-abi 
aapcs-soft -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple armv8.1m.main -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple aarch64 -fsyntax-only -verify=sve-type
+// RUN: %clang_cc1 %s -triple aarch64 -target-feature -fp-armv8 -target-abi 
aapcs-soft -fsyntax-only -verify=sve-type
 
-typedef __attribute__((neon_vector_type(2))) int int32x2_t; // 
expected-error{{'neon_vector_type' attribute is not supported on targets 
missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or 
-mcpu=}}
-typedef __attribute__((neon_polyvector_type(16))) short poly8x16_t; // 
expected-error{{'neon_polyvector_type' attribute is not supported on targets 
missing 'neon' or 'mve'; specify an appropriate -march= or -mcpu=}}
+typedef __attribute__((neon_vector_type(2))) int int32x2_t; // 
expected-error{{'neon_vector_type' attribute is not supported on targets 
missing 'mve'; specify an appropriate -march= or -mcpu=}}

mgabka wrote:

this error message does not sound like the one we are expecting to see as that 
suggests that "neon_vector_type'' is only supported when target supports mve. 
What I believe is not true. 

>From the changes to SemaType.cpp it looks like you want to emit this error 
>only when the requested target is an m class architecture, this should be 
>reflected in the error message.


But I am surprised that the run line:
RUN: %clang_cc1 %s -triple aarch64 -fsyntax-only -verify=sve-type

still generates this error.


https://github.com/llvm/llvm-project/pull/95224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

[Maciej Gabka via cfe-commits]

@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 %s -triple armv7 -fsyntax-only -verify
-// RUN: %clang_cc1 %s -triple aarch64 -fsyntax-only -verify
-// RUN: %clang_cc1 %s -triple aarch64 -target-feature -fp-armv8 -target-abi 
aapcs-soft -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple armv8.1m.main -fsyntax-only -verify
+// RUN: %clang_cc1 %s -triple aarch64 -fsyntax-only -verify=sve-type
+// RUN: %clang_cc1 %s -triple aarch64 -target-feature -fp-armv8 -target-abi 
aapcs-soft -fsyntax-only -verify=sve-type
 
-typedef __attribute__((neon_vector_type(2))) int int32x2_t; // 
expected-error{{'neon_vector_type' attribute is not supported on targets 
missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or 
-mcpu=}}
-typedef __attribute__((neon_polyvector_type(16))) short poly8x16_t; // 
expected-error{{'neon_polyvector_type' attribute is not supported on targets 
missing 'neon' or 'mve'; specify an appropriate -march= or -mcpu=}}
+typedef __attribute__((neon_vector_type(2))) int int32x2_t; // 
expected-error{{'neon_vector_type' attribute is not supported on targets 
missing 'mve'; specify an appropriate -march= or -mcpu=}}

mgabka wrote:

sorry, it was some time since I was working on sema, i didn't realise that 
"-verify=sve-type" make it only apply to the errors tagged with 
"sve-type-error@".


Is the error message used anywhere else? if not I personally am not against 
changing the error message, to be specific to M class processors.

https://github.com/llvm/llvm-project/pull/95224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

[Maciej Gabka via cfe-commits]

@@ -8086,23 +8086,21 @@ static void HandleNeonVectorTypeAttr(QualType &CurType, 
const ParsedAttr &Attr,
 
   // Target must have NEON (or MVE, whose vectors are similar enough
   // not to need a separate attribute)
-  if (!(S.Context.getTargetInfo().hasFeature("neon") ||
-S.Context.getTargetInfo().hasFeature("mve") ||
-S.Context.getTargetInfo().hasFeature("sve") ||
-S.Context.getTargetInfo().hasFeature("sme") ||
+  if (!(S.Context.getTargetInfo().hasFeature("mve") ||
 IsTargetCUDAAndHostARM) &&

mgabka wrote:

it looks to me like the logic here can be simplified and use of this variable 
can be removed entirely.

After reading 
https://github.com/llvm/llvm-project/commit/8b0ea48740935d819618d8254fc45d98179b672c

It looks to me like somebody already disabled these errors when targeting GPUs, 
so we could just simplify the logic and emit the errors only when user targets 
M class CPUs, what do you think?


https://github.com/llvm/llvm-project/pull/95224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

[Maciej Gabka via cfe-commits]

@@ -8086,23 +8086,21 @@ static void HandleNeonVectorTypeAttr(QualType &CurType, 
const ParsedAttr &Attr,
 
   // Target must have NEON (or MVE, whose vectors are similar enough
   // not to need a separate attribute)
-  if (!(S.Context.getTargetInfo().hasFeature("neon") ||
-S.Context.getTargetInfo().hasFeature("mve") ||
-S.Context.getTargetInfo().hasFeature("sve") ||
-S.Context.getTargetInfo().hasFeature("sme") ||
+  if (!(S.Context.getTargetInfo().hasFeature("mve") ||
 IsTargetCUDAAndHostARM) &&

mgabka wrote:

I am suggesting that in that patch we removed error emission when targeting 
GPU, since now we are restricting error emission to M class processors, I think 
the extra handling for GPUS can be removed.

https://github.com/llvm/llvm-project/pull/95224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

@@ -1099,6 +1099,25 @@ static bool upgradeIntrinsicFunction1(Function *F, 
Function *&NewFn,
 return true;
   }
 
+  ID = StringSwitch(Name)
+   .StartsWith("splice.", Intrinsic::vector_splice)
+   .StartsWith("reverse.", Intrinsic::vector_reverse)
+   .StartsWith("interleave2.", Intrinsic::vector_interleave2)
+   .StartsWith("deinterleave2.", Intrinsic::vector_deinterleave2)
+   .Default(Intrinsic::not_intrinsic);
+  if (ID != Intrinsic::not_intrinsic) {
+const auto *FT = F->getFunctionType();
+rename(F);
+if (ID == Intrinsic::vector_interleave2)
+  NewFn = Intrinsic::getDeclaration(F->getParent(), ID,
+FT->getReturnType());
+else {

mgabka wrote:

Thanks for pointing this out, decided to merge this with the similar section 
for insert/extract.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

@@ -18779,13 +18779,13 @@ This is an overloaded intrinsic.
 
 ::
 
-  declare <2 x i8> @llvm.experimental.vector.reverse.v2i8(<2 x i8> %a)
-  declare  
@llvm.experimental.vector.reverse.nxv4i32( %a)
+  declare <2 x i8> @llvm.vector.reverse.v2i8(<2 x i8> %a)
+  declare  @llvm.vector.reverse.nxv4i32( %a)
 
 Overview:
 "
 
-The '``llvm.experimental.vector.reverse.*``' intrinsics reverse a vector.
+The '``llvm.vector.reverse.*``' intrinsics reverse a vector.
 The intrinsic takes a single vector and returns a vector of matching type but
 with the original lane order reversed. These intrinsics work for both fixed
 and scalable vectors. While this intrinsic is marked as experimental the

mgabka wrote:

Sorry I missed it.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

@@ -18914,13 +18914,13 @@ This is an overloaded intrinsic.
 
 ::
 
-  declare <2 x double> @llvm.experimental.vector.splice.v2f64(<2 x double> 
%vec1, <2 x double> %vec2, i32 %imm)
-  declare  
@llvm.experimental.vector.splice.nxv4i32( %vec1,  %vec2, i32 %imm)
+  declare <2 x double> @llvm.vector.splice.v2f64(<2 x double> %vec1, <2 x 
double> %vec2, i32 %imm)
+  declare  @llvm.vector.splice.nxv4i32( %vec1,  %vec2, i32 %imm)
 
 Overview:
 "
 
-The '``llvm.experimental.vector.splice.*``' intrinsics construct a vector by
+The '``llvm.vector.splice.*``' intrinsics construct a vector by

mgabka wrote:

Sorry I missed it.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

> > vector.revert
> 
> I think should be vector.reverse?

Will fix the commit message when merging the PR.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka edited https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

I was actually following this patch https://reviews.llvm.org/D127976 which 
promoted vector.insert/extract and there was no RFC for it.
My understanding is that these intrinsics are so heavily used in LLVM now so 
there is no need to call them experimental, moreover the auto upgrade ensures 
that the "experimental" name is still honoured.

My plan was to promote stepvector as well in separate PR.

I am happy to raise an RFC if you feel that it is worth it.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

Added a message here: 
https://discourse.llvm.org/t/rfc-promoting-experimental-interleave2-deinterleave2-reverse-splice-and-stepvector-intrinsics-to-first-class-intrinsics/78414

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][NEON] Add neon target guard to intrinsics (PR #98624)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +dotprod  
-target-feature +fullfp16 -target-feature +fp16fml -target-feature +i8mm 
-target-feature +bf16 -verify -emit-llvm -o - %s
+
+// This test is testing the diagnostics that Clang emits when compiling 
without '+neon'.

mgabka wrote:

do we have a positive Sema tests to show that the intrinsics are available when 
the neon feature is present?

https://github.com/llvm/llvm-project/pull/98624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

Rebased on newer LLVM + forcing to re-run the testing which previously failed 
on some not related issues.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

@c-rhodes  the remaining failure is  MLIR :: 
Conversion/TosaToTensor/tosa-to-tensor.mlir but it also fails without my 
changes.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,46 @@
+; RUN: opt -S < %s | FileCheck %s

mgabka wrote:

I would prefer to keep it, as this is checking it the auto upgrade triggers 
when we have IR->IR transformation, while the other RUN line is about 
IR->bitcode->IR flow, and they could use same functionality but from user 
perspective these are different use cases in my opinion.

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,132 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --filter "call.*(frexp|modf)" --version 4
+; RUN: opt < %s -mattr=+sve -vector-library=ArmPL 
-passes=inject-tli-mappings,loop-vectorize -force-vector-interleave=1 
-prefer-predicate-over-epilogue=predicate-dont-vectorize -S | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
+
+; TODO: add mappings for frexp/frexpf

mgabka wrote:

is this actually a TODO?
I would rather change it into a comment:

; Vectorization can not happen because there is no scalar to vector mapping in 
TLI for frexp/frexpf. Tests will need to be changed when such mapping are added.

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -2422,6 +2438,15 @@ void LoopAccessInfo::analyzeLoop(AAResults *AA, LoopInfo 
*LI,
 
   // Save 'store' instructions. Abort if other instructions write to 
memory.
   if (I.mayWriteToMemory()) {
+// We can safety handle math functions that have vectorized
+// counterparts and have the memory write-only attribute set.
+if (isMathLibCallMemWriteOnly(TLI, I)) {
+  LLVM_DEBUG(dbgs()
+ << "LAA: allow math function with write-only attribute:"

mgabka wrote:

I think it is worth to edit this message a bit so it gives the full context in 
dbg output, what about:
"LAA: Allow to vectorize math function with write-only attribute:" ?

(also the dbg message start from capital letter)

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,117 @@
+; RUN: opt < %s -mattr=+sve -vector-library=ArmPL 
-passes=inject-tli-mappings,loop-vectorize -debug-only=loop-accesses 
-disable-output 2>&1 | FileCheck %s
+
+; REQUIRES: asserts
+
+target triple = "aarch64-unknown-linux-gnu"
+
+; TODO: add mappings for frexp/frexpf

mgabka wrote:

you can still test for the expected dbg output even if there is no mappings, 
mappings are tested later by LV I think.

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,117 @@
+; RUN: opt < %s -mattr=+sve -vector-library=ArmPL 
-passes=inject-tli-mappings,loop-vectorize -debug-only=loop-accesses 
-disable-output 2>&1 | FileCheck %s

mgabka wrote:

I think you should only be calling here : "-passes='print' 
-debug-only=loop-accesses -disable-output" 

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -2422,6 +2438,15 @@ void LoopAccessInfo::analyzeLoop(AAResults *AA, LoopInfo 
*LI,
 
   // Save 'store' instructions. Abort if other instructions write to 
memory.
   if (I.mayWriteToMemory()) {
+// We can safety handle math functions that have vectorized
+// counterparts and have the memory write-only attribute set.
+if (isMathLibCallMemWriteOnly(TLI, I)) {

mgabka wrote:

in the read case we also check for !VFDatabase::getMappings(*Call).empty(), but 
i think it should be enough that LV checks for it, that allows also to test 
your code in a target agnostic way, and without mappings for frexp

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

mgabka wrote:

I needed to adjust one more test after another rebase:
llvm/test/Transforms/LoopVectorize/AArch64/reduction-recurrence-costs-sve.ll 

I am merging it know without waiting for the pre commit validation, otrherwise 
will most likely need to update another tests etc. 

https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [mlir] Move several vector intrinsics out of experimental namespace (PR #88748)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka closed https://github.com/llvm/llvm-project/pull/88748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -0,0 +1,134 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --filter "call.*(frexp|modf)" --version 4

mgabka wrote:

sincos (which also takes linear pointers) has tests inside 
veclib-function-calls.ll, so I would suggest to move this tests to the same 
file.

https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka approved this pull request.


https://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Maciej Gabka via cfe-commits]

@@ -2477,6 +2493,15 @@ void LoopAccessInfo::analyzeLoop(AAResults *AA, LoopInfo 
*LI,
 
   // Save 'store' instructions. Abort if other instructions write to 
memory.
   if (I.mayWriteToMemory()) {
+// We can safety handle math functions that have vectorized
+// counterparts and have the memory write-only attribute set.

mgabka wrote:

Hi @fhahn,
you are right.

The whole logic was based on checking later in the  
https://github.com/llvm/llvm-project/blob/332de4b2677ce7a95cc2df30d761fbb55376fe07/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L6659
 if the pointers are linear with the right step, but there is no checks for 
aliasing.
@paschalis-mpeis that means that there is an existing bug with sincos, as 
following code gets vectorised, without any checks:

```
double sin[N];
double cos[N];
sin[5] = M_PI;

for(int i=0; ihttps://github.com/llvm/llvm-project/pull/78432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Remove preprocessor guards and global feature checks for NEON (PR #95224)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka approved this pull request.


https://github.com/llvm/llvm-project/pull/95224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Make -fveclib={ArmPL, SLEEF} imply -fno-math-errno (PR #112580)

[Maciej Gabka via cfe-commits]

@@ -36,16 +36,23 @@
 /* Verify that the correct vector library is passed to LTO flags. */
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -fveclib=LIBMVEC -flto 
%s 2>&1 | FileCheck --check-prefix=CHECK-LTO-LIBMVEC %s
+// CHECK-LTO-LIBMVEC: "-fmath-errno"
 // CHECK-LTO-LIBMVEC: "-plugin-opt=-vector-library=LIBMVEC-X86"
 
 // RUN: %clang -### --target=powerpc64-unknown-linux-gnu -fveclib=MASSV -flto 
%s 2>&1 | FileCheck --check-prefix=CHECK-LTO-MASSV %s
+// CHECK-LTO-MASSV: "-fmath-errno"
 // CHECK-LTO-MASSV: "-plugin-opt=-vector-library=MASSV"
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -fveclib=SVML -flto %s 
2>&1 | FileCheck --check-prefix=CHECK-LTO-SVML %s
+// CHECK-LTO-SVML: "-fmath-errno"
 // CHECK-LTO-SVML: "-plugin-opt=-vector-library=SVML"
 
 // RUN: %clang -### --target=aarch64-linux-gnu -fveclib=SLEEF -flto %s 2>&1 | 
FileCheck --check-prefix=CHECK-LTO-SLEEF %s
+// CHECK-LTO-SLEEF-NOT: "-fmath-errno"
 // CHECK-LTO-SLEEF: "-plugin-opt=-vector-library=sleefgnuabi"
+// CHECK-LTO-SLEEF-NOT: "-fmath-errno"
 
 // RUN: %clang -### --target=aarch64-linux-gnu -fveclib=ArmPL -flto %s 2>&1 | 
FileCheck --check-prefix=CHECK-LTO-ARMPL %s
+// CHECK-LTO-ARMPL-NOT: "-fmath-errno"

mgabka wrote:

Thanks @MacDue for these changes, personally I find the warning in the current 
form helpful, although it  feels to me like it combines 2 things:

1. warning that math-errno got re-enabled
2. loop vectorizer optimization remark suggesting to use -fno-math-errno to 
enable vectorization loops calling math functions.

Do we have the pt 2 already?



https://github.com/llvm/llvm-project/pull/112580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Make -fveclib={ArmPL, SLEEF} imply -fno-math-errno (PR #112580)

[Maciej Gabka via cfe-commits]

@@ -36,16 +36,23 @@
 /* Verify that the correct vector library is passed to LTO flags. */
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -fveclib=LIBMVEC -flto 
%s 2>&1 | FileCheck --check-prefix=CHECK-LTO-LIBMVEC %s
+// CHECK-LTO-LIBMVEC: "-fmath-errno"
 // CHECK-LTO-LIBMVEC: "-plugin-opt=-vector-library=LIBMVEC-X86"
 
 // RUN: %clang -### --target=powerpc64-unknown-linux-gnu -fveclib=MASSV -flto 
%s 2>&1 | FileCheck --check-prefix=CHECK-LTO-MASSV %s
+// CHECK-LTO-MASSV: "-fmath-errno"
 // CHECK-LTO-MASSV: "-plugin-opt=-vector-library=MASSV"
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu -fveclib=SVML -flto %s 
2>&1 | FileCheck --check-prefix=CHECK-LTO-SVML %s
+// CHECK-LTO-SVML: "-fmath-errno"
 // CHECK-LTO-SVML: "-plugin-opt=-vector-library=SVML"
 
 // RUN: %clang -### --target=aarch64-linux-gnu -fveclib=SLEEF -flto %s 2>&1 | 
FileCheck --check-prefix=CHECK-LTO-SLEEF %s
+// CHECK-LTO-SLEEF-NOT: "-fmath-errno"
 // CHECK-LTO-SLEEF: "-plugin-opt=-vector-library=sleefgnuabi"
+// CHECK-LTO-SLEEF-NOT: "-fmath-errno"
 
 // RUN: %clang -### --target=aarch64-linux-gnu -fveclib=ArmPL -flto %s 2>&1 | 
FileCheck --check-prefix=CHECK-LTO-ARMPL %s
+// CHECK-LTO-ARMPL-NOT: "-fmath-errno"

mgabka wrote:

I think it might be worth to add tests for "-fveclib=ArmPL -fmath-errno" and 
similar for sleefm to ensure that the order of flags in properly honoured.

https://github.com/llvm/llvm-project/pull/112580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Make -fveclib={ArmPL, SLEEF} imply -fno-math-errno (PR #112580)

[Maciej Gabka via cfe-commits]

@@ -3125,6 +3129,10 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   TrappingMathPresent = true;
   FPExceptionBehavior = "strict";
   break;
+case options::OPT_fveclib:
+  if (llvm::is_contained(VecLibImpliesNoMathErrno, A->getValue()))
+MathErrno = false;
+  break;

mgabka wrote:

I don't thinks so, these 2 libraries are stating clearly that they do not 
honour errno regardless of the platform. Well in ArmPL case is supports only 
Arm, but SLEEF could work on other targets if the right mappings were added to 
LLVM.

https://github.com/llvm/llvm-project/pull/112580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [AArch64] Reduce +sve2-aes to an alias of +sve-aes+sve2 (PR #114293)

[Maciej Gabka via cfe-commits]

@@ -369,9 +369,12 @@ def FeatureSVE2 : ExtensionWithMArch<"sve2", "SVE2", 
"FEAT_SVE2",
   "Enable Scalable Vector Extension 2 (SVE2) instructions",
   [FeatureSVE, FeatureUseScalarIncVL]>;
 
-def FeatureSVE2AES : ExtensionWithMArch<"sve2-aes", "SVE2AES",
+def FeatureSVEAES : ExtensionWithMArch<"sve-aes", "SVEAES",
   "FEAT_SVE_AES, FEAT_SVE_PMULL128",
-  "Enable AES SVE2 instructions", [FeatureSVE2, FeatureAES]>;
+  "Enable SVE AES and 128-bit PMULL instructions", [FeatureAES]>;

mgabka wrote:

I think what you mean is:
"Enable SVE AES and SVE PMULL instructions", am I right? or you actually meant 
Neon PMULL?


https://github.com/llvm/llvm-project/pull/114293
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [AArch64] Reduce +sve2-aes to an alias of +sve-aes+sve2 (PR #114293)

[Maciej Gabka via cfe-commits]

@@ -369,9 +369,12 @@ def FeatureSVE2 : ExtensionWithMArch<"sve2", "SVE2", 
"FEAT_SVE2",
   "Enable Scalable Vector Extension 2 (SVE2) instructions",
   [FeatureSVE, FeatureUseScalarIncVL]>;
 
-def FeatureSVE2AES : ExtensionWithMArch<"sve2-aes", "SVE2AES",
+def FeatureSVEAES : ExtensionWithMArch<"sve-aes", "SVEAES",
   "FEAT_SVE_AES, FEAT_SVE_PMULL128",
-  "Enable AES SVE2 instructions", [FeatureSVE2, FeatureAES]>;
+  "Enable SVE AES and 128-bit PMULL instructions", [FeatureAES]>;
+
+def FeatureSVE2AES : ExtensionWithMArch<"sve2-aes", "SVE2AES", "",
+  "An alias of +sve2+sve-aes", [FeatureSVE2, FeatureSVEAES]>;

mgabka wrote:

>From what I am reading there is nothing in LLVM like a feature alias, I would 
>suggest to document it as a next new feature which enables sve2 and sve-aes 
>etc 

https://github.com/llvm/llvm-project/pull/114293
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][doc] Add release note for changes to `-fveclib={ArmPL,SLEEF}` (PR #113673)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka approved this pull request.


https://github.com/llvm/llvm-project/pull/113673
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lldb] [llvm] [AArch64] Reduce +sve2-aes to an alias of +sve-aes+sve2 (PR #114293)

[Maciej Gabka via cfe-commits]

@@ -369,9 +369,12 @@ def FeatureSVE2 : ExtensionWithMArch<"sve2", "SVE2", 
"FEAT_SVE2",
   "Enable Scalable Vector Extension 2 (SVE2) instructions",
   [FeatureSVE, FeatureUseScalarIncVL]>;
 
-def FeatureSVE2AES : ExtensionWithMArch<"sve2-aes", "SVE2AES",
+def FeatureSVEAES : ExtensionWithMArch<"sve-aes", "SVEAES",
   "FEAT_SVE_AES, FEAT_SVE_PMULL128",
-  "Enable AES SVE2 instructions", [FeatureSVE2, FeatureAES]>;
+  "Enable SVE AES and 128-bit PMULL instructions", [FeatureAES]>;

mgabka wrote:

I think that would be more clear, from the original text I think it looked more 
like the SVE relates only to the AES, not to PMULL, and PMULL has variants for 
NEON and SVE.

https://github.com/llvm/llvm-project/pull/114293
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add AArch64 SME changes to the release notes (PR #122899)

[Maciej Gabka via cfe-commits]

@@ -1076,6 +1076,15 @@ Arm and AArch64 Support
   in leaf functions after enabling ``-fno-omit-frame-pointer``, you can do so 
by adding
   the ``-momit-leaf-frame-pointer`` option.
 
+- SME keyword attributes which apply to function types are now represented in 
the
+  mangling of the type.  This means that ``void foo(void (*f)() 
__arm_streaming);``

mgabka wrote:

it looks like there is a double white space after "type."

https://github.com/llvm/llvm-project/pull/122899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Add AArch64 SME changes to the release notes (PR #122899)

[Maciej Gabka via cfe-commits]

https://github.com/mgabka approved this pull request.


https://github.com/llvm/llvm-project/pull/122899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits