[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/utils/TableGen/TableGen.cpp:196
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",

sdesmalen wrote:
> thakis wrote:
> > Any reason these aren't called `-gen-arm-sve-builtin-def` and 
> > `-gen-arm-sve-builtin-codegen` for consistency with CDE and MVE?
> Not really, I can change that.
Looks like you renamed the files to be consistent (thanks!), but not the flag 
names. Can you make those consistent too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/utils/TableGen/SveEmitter.cpp:32
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 

sdesmalen wrote:
> thakis wrote:
> > Including stuff from `clang/Basic` in clang/utils/TableGen is conceptually 
> > a layering violation: clang-tblgen is used to generate headers included in 
> > clang/Basic. In this case it happens to work, but it's because you're 
> > lucky, and it could break for subtle reasons if the TypeFlags header starts 
> > including some other header in Basic that happens to include something 
> > generated.
> > 
> > Please restructure this so that the TableGen code doesn't need an include 
> > from Basic.
> Thanks for pointing out! The only directory that seems to have common 
> includes between Clang TableGen/CodeGen is the llvm/Support directory, any 
> objection to me moving the header there?
That seems like a strange place for this header.

Maybe you can rework things so that you don't have to share a header between 
clang's tablegen and clang's Basic? No other tablegen output so far has needed 
that. (see e.g. the `  /// These must be kept in sync with the flags in 
utils/TableGen/NeonEmitter.h.` line in TargetBuiltins.h).

If that isn't possible at all, I suppose you could put the .h file in 
clang/utils/TableGen and also make clang-tblgen write the .h file and use the 
written .h file in Basic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Raphael Isemann via Phabricator via cfe-commits]

teemperor added a comment.

This patch broke the Clang build with enabled modules (which is used by the 
LLDB bot, but every other bot is also dead: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen marked 2 inline comments as done.
sdesmalen added inline comments.



Comment at: clang/utils/TableGen/SveEmitter.cpp:32
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 

thakis wrote:
> Including stuff from `clang/Basic` in clang/utils/TableGen is conceptually a 
> layering violation: clang-tblgen is used to generate headers included in 
> clang/Basic. In this case it happens to work, but it's because you're lucky, 
> and it could break for subtle reasons if the TypeFlags header starts 
> including some other header in Basic that happens to include something 
> generated.
> 
> Please restructure this so that the TableGen code doesn't need an include 
> from Basic.
Thanks for pointing out! The only directory that seems to have common includes 
between Clang TableGen/CodeGen is the llvm/Support directory, any objection to 
me moving the header there?



Comment at: clang/utils/TableGen/TableGen.cpp:196
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",

thakis wrote:
> Any reason these aren't called `-gen-arm-sve-builtin-def` and 
> `-gen-arm-sve-builtin-codegen` for consistency with CDE and MVE?
Not really, I can change that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/utils/TableGen/SveEmitter.cpp:32
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 

Including stuff from `clang/Basic` in clang/utils/TableGen is conceptually a 
layering violation: clang-tblgen is used to generate headers included in 
clang/Basic. In this case it happens to work, but it's because you're lucky, 
and it could break for subtle reasons if the TypeFlags header starts including 
some other header in Basic that happens to include something generated.

Please restructure this so that the TableGen code doesn't need an include from 
Basic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/include/clang/Basic/CMakeLists.txt:44
 
 # ARM NEON and MVE
 clang_tablegen(arm_neon.inc -gen-arm-neon-sema

Update comment to also say "SVE" and "CDE" (or just say "# ARM builtin headers")



Comment at: clang/utils/TableGen/TableGen.cpp:196
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",

Any reason these aren't called `-gen-arm-sve-builtin-def` and 
`-gen-arm-sve-builtin-codegen` for consistency with CDE and MVE?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8b409eabaf75: [SVE] Auto-generate builtins and header for 
svld1. (authored by sdesmalen).

Changed prior to commit:
  https://reviews.llvm.org/D75470?vs=249312&id=250509#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470

Files:
  clang/include/clang/Basic/AArch64SVETypeFlags.h
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/include/clang/Basic/BuiltinsSVE.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -92,6 +92,8 @@
 void EmitNeonTest2(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitSveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveCodeGenMap(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -71,6 +71,8 @@
   GenArmMveBuiltinCG,
   GenArmMveBuiltinAliases,
   GenArmSveHeader,
+  GenArmSveBuiltins,
+  GenArmSveCodeGenMap,
   GenArmCdeHeader,
   GenArmCdeBuiltinDef,
   GenArmCdeBuiltinSema,
@@ -188,6 +190,10 @@
"Generate ARM NEON tests for clang"),
 clEnumValN(GenArmSveHeader, "gen-arm-sve-header",
"Generate arm_sve.h for clang"),
+clEnumValN(GenArmSveBuiltins, "gen-arm-sve-builtins",
+   "Generate arm_sve_builtins.inc for clang"),
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -372,6 +378,12 @@
   case GenArmSveHeader:
 EmitSveHeader(Records, OS);
 break;
+  case GenArmSveBuiltins:
+EmitSveBuiltins(Records, OS);
+break;
+  case GenArmSveCodeGenMap:
+EmitSveCodeGenMap(Records, OS);
+break;
   case GenArmCdeHeader:
 EmitCdeHeader(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -29,6 +29,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 
 #include 
 #include 
@@ -36,26 +37,535 @@
 
 using namespace llvm;
 
-//===--===//
-// SVEEmitter
-//===--===//
+enum ClassKind {
+  ClassNone,
+  ClassS, // signed/unsigned, e.g., "_s8", "_u8" suffix
+  ClassG, // Overloaded name without type suffix
+};
+
+using TypeSpec = std::string;
+using SVETypeFlags = clang::SVETypeFlags;
 
 namespace {
 
+class SVEType {
+  TypeSpec TS;
+  bool Float, Signed, Immediate, Void, Constant, Pointer;
+  bool DefaultType, IsScalable, Predicate, PredicatePattern, PrefetchOp;
+  unsigned Bitwidth, ElementBitwidth, NumVectors;
+
+public:
+  SVEType() : SVEType(TypeSpec(), 'v') {}
+
+  SVEType(TypeSpec TS, char CharMod)
+  : TS(TS), Float(false), Signed(true), Immediate(false), Void(false),
+Constant(false), Pointer(false), DefaultType(false), IsScalable(true),
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())
+  applyTypespec();
+applyModifier(CharMod);
+  }
+
+  /// Return the value in SVETypeFlags for this type.
+  unsigned getTypeFlags() const;
+
+  bool isPointer() const { return Pointer; }
+  bool isVoidPointer() const { return Pointer && Void; }
+  bool isSigned() const { return Signed; }
+  bool isImmediate() const { return Immediate; }
+  bool isScalar() const { return NumVectors == 0; }
+  bool isVector() const { return NumVectors > 0; }
+  bool isScalableVector() const { return isVector() && IsScalable; }
+  bool isChar() const { return ElementBitwidth == 8; }
+  bool isVoid() 

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sjoerd Meijer via Phabricator via cfe-commits]

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

Cheers, I think this looks very reasonable.


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen marked an inline comment as done.
sdesmalen added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:5292
+  { #NameBase, SVE::BI__builtin_sve_##NameBase, 0, 0, TypeModifier }
+static const NeonIntrinsicInfo AArch64SVEIntrinsicMap[] = {
+#define GET_SVE_LLVM_INTRINSIC_MAP

SjoerdMeijer wrote:
> I am wondering if it is confusing/correct to use NeonInstrinsicInfo here?
We can reuse the same info-struct and find function, but the names are indeed 
misleading. I've renamed these.


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen updated this revision to Diff 249312.
sdesmalen added a comment.

s/NeonIntrinsicInfo/ARMVectorIntrinsicInfo/
s/findNeonIntrinsicInMap/findARMVectorIntrinsicInMap/


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

https://reviews.llvm.org/D75470

Files:
  clang/include/clang/Basic/AArch64SVETypeFlags.h
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/include/clang/Basic/BuiltinsSVE.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -92,6 +92,8 @@
 void EmitNeonTest2(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitSveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveCodeGenMap(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -71,6 +71,8 @@
   GenArmMveBuiltinCG,
   GenArmMveBuiltinAliases,
   GenArmSveHeader,
+  GenArmSveBuiltins,
+  GenArmSveCodeGenMap,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -183,6 +185,10 @@
"Generate ARM NEON tests for clang"),
 clEnumValN(GenArmSveHeader, "gen-arm-sve-header",
"Generate arm_sve.h for clang"),
+clEnumValN(GenArmSveBuiltins, "gen-arm-sve-builtins",
+   "Generate arm_sve_builtins.inc for clang"),
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -357,6 +363,12 @@
   case GenArmSveHeader:
 EmitSveHeader(Records, OS);
 break;
+  case GenArmSveBuiltins:
+EmitSveBuiltins(Records, OS);
+break;
+  case GenArmSveCodeGenMap:
+EmitSveCodeGenMap(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -29,6 +29,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 
 #include 
 #include 
@@ -36,12 +37,201 @@
 
 using namespace llvm;
 
-//===--===//
-// SVEEmitter
-//===--===//
+enum ClassKind {
+  ClassNone,
+  ClassS, // signed/unsigned, e.g., "_s8", "_u8" suffix
+  ClassG, // Overloaded name without type suffix
+};
+
+using TypeSpec = std::string;
+using SVETypeFlags = clang::SVETypeFlags;
 
 namespace {
 
+class SVEType {
+  TypeSpec TS;
+  bool Float, Signed, Immediate, Void, Constant, Pointer;
+  bool DefaultType, IsScalable, Predicate, PredicatePattern, PrefetchOp;
+  unsigned Bitwidth, ElementBitwidth, NumVectors;
+
+public:
+  SVEType() : SVEType(TypeSpec(), 'v') {}
+
+  SVEType(TypeSpec TS, char CharMod)
+  : TS(TS), Float(false), Signed(true), Immediate(false), Void(false),
+Constant(false), Pointer(false), DefaultType(false), IsScalable(true),
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())
+  applyTypespec();
+applyModifier(CharMod);
+  }
+
+  /// Return the value in SVETypeFlags for this type.
+  unsigned getTypeFlags() const;
+
+  bool isPointer() const { return Pointer; }
+  bool isVoidPointer() const { return Pointer && Void; }
+  bool isSigned() const { return Signed; }
+  bool isImmediate() const { return Immediate; }
+  bool isScalar() const { return NumVectors == 0; }
+  bool isVector() const { return NumVectors > 0; }
+  bool isScalableVector() const { return isVector() && IsScalable; }
+  bool isChar() const { return ElementBitwidth == 8; }
+  bool isVoid() const { return Void & !Pointer; }
+  bool isDefault() const { return DefaultType; }
+  bool isFloat() const { return Float; }
+  bool isInteger() const { 

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:5292
+  { #NameBase, SVE::BI__builtin_sve_##NameBase, 0, 0, TypeModifier }
+static const NeonIntrinsicInfo AArch64SVEIntrinsicMap[] = {
+#define GET_SVE_LLVM_INTRINSIC_MAP

I am wondering if it is confusing/correct to use NeonInstrinsicInfo here?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7456
+
+  auto *Builtin = findNeonIntrinsicInMap(AArch64SVEIntrinsicMap, BuiltinID,
+ AArch64SVEIntrinsicsProvenSorted);

and the same here: findNeon...


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Mikhail Maltsev via Phabricator via cfe-commits]

miyuki added a comment.

In D75470#1910071 , @sdesmalen wrote:

> The SVE implementation now does more or less the same thing the MVE 
> implementation; `arm_sve.h` also uses `__attribute__((overloadable))` and 
> `__attribute__((arm_sve_alias("__builtin_...")))`, the latter only to declare 
> the overloaded intrinsics. That means we get the same benefits as Simon 
> described.


FYI: we are currently working on another M-profile extension, CDE. In my 
patches am reusing some of the MVE intrinsic machinery, and I decided to rename 
`__clang_arm_mve_alias` to `__clang_arm_builtin_alias`. You might want to reuse 
the same attribute name to reduce duplication, see 
https://reviews.llvm.org/D75850


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen marked an inline comment as done.
sdesmalen added a comment.
Herald added a subscriber: danielkiss.

In D75470#1907562 , @SjoerdMeijer 
wrote:

> Adding @simon_tatham in case he feels wants to have a look too.


Thanks Sjoerd! @simon_tatham and I had a chat about this offline today.

The SVE implementation now does more or less the same thing the MVE 
implementation; `arm_sve.h` also uses `__attribute__((overloadable))` and 
`__attribute__((arm_sve_alias("__builtin_...")))`, the latter only to declare 
the overloaded intrinsics. That means we get the same benefits as Simon 
described.

There are a few details that are different:

- The MVE implementation *does not* use the type string in the actual 
Builtins.def. For example, the type string below is not `"V16ScV16ScV16Sci"`, 
but rather `""`:


  TARGET_HEADER_BUILTIN(__builtin_arm_mve_vcaddq_rot270_f16, "", "n", 
"arm_mve.h", ALL_LANGUAGES, "")

- This means that the implementation relies solely on the declaration in 
arm_mve.h to define the intrinsic prototype.
- If I understood this correctly, this is currently needed to represent the 
tuple types (which cannot yet be expressed in the bulitin type string format) 
returned from structured loads like ld2/ld3/ld4.

The SVE implementation *does* use the type string in Builtins.def.

- For SVE, the structured loads will just return a wider vector with 2, 3 or 4 
times the number of elements, so the lack of support in the builtin type-string 
format is not an issue.
- An advantage of that is that we can use a `#define svadd_u8(...) 
__builtin_svadd_u8(...)` for the non-overloaded builtins which helps 
compile-time performance.

If all the intrinsics can be described *with* a builtin type string, we can 
actually work to define all builtins internally in Clang (as @efriedma 
suggested in D75298 ) rather than having to 
rely on the header file to define the prototypes, hopefully get rid of the 
expensive header file.
When we do this for SVE, MVE can probably follow the same approach.




Comment at: clang/include/clang/Basic/arm_sve.td:121
+// Load one vector (scalar base)
+def SVLD1   : MInst<"svld1[_{2}]", "dPc", "csilUcUsUiUlhfd", [IsLoad]>;

simon_tatham wrote:
> SjoerdMeijer wrote:
> > sdesmalen wrote:
> > > SjoerdMeijer wrote:
> > > > This encoding, e.g, this is  "csilUcUsUiUlhfd", is such a monstrosity. 
> > > > It's a very efficient encoding, but of course completely unreadable.  I 
> > > > know there is prior art, and know that this is how it's been done, but 
> > > > just curious if you have given it thoughts how to do this in a normal 
> > > > way, a bit more c++y.  I don't want to de-rail this work, but if we are 
> > > > adding a new emitter, perhaps now is the time to give it a thought, so 
> > > > was just curious.  
> > > Haha, its a bit of a monstrosity indeed. The only thing I can think of 
> > > here would be having something like:
> > > ```class TypeSpecs val> {
> > >   list v = val;
> > > }
> > > def All_Int_Float_Ty : TypeSpecs<["c", "s", "i", "l", "Uc", "Us", "Ul", 
> > > "h", "f", "d">;
> > > 
> > > def SVLD1 : Minst<"svld1[_{2}]", "dPc", All_Int_Float_Ty, [IsLoad]>;```
> > > 
> > > But I suspect this gets a bit awkward because of the many permutations, I 
> > > count more than 40. Not sure if that would really improve the readability.
> > I would personally welcome any improvement here, even the smallest. But if 
> > you think it's tricky, then fair enough!
> > 
> > I've managed to completely ignore the MVE intrinsics work so far, but 
> > understood there were some innovations here and there (e.g. in tablegen). 
> > Probably because it is dealing with similar problems: a lot of intrinsics, 
> > some of them overloaded with different types. I'm going to have a little 
> > look now to see if there's anything we can borrow from that, or if that is 
> > unrelated
> In the MVE intrinsics implementation I completely avoided that entire system 
> of string-based type specifications. There's another completely different way 
> you can set up the types of builtins, and I used that instead.
> 
> You can declare the function for `Builtins.def` purposes with no type 
> specification at all, and then you fill in its type signature using a 
> declaration in the //header file//, with the unusual combination of 
> `__inline__` and no function body:
> ```static __inline__ int32x4_t __builtin_arm_foo_bar(int16x8_t, float23x7t); 
> // or whatever```
> 
> In fact I went one step further: the user-facing names for the MVE intrinsics 
> are declared in `arm_mve.h` with a special attribute indicating that they're 
> aliases for clang builtins. And the MVE polymorphic intrinsics are done by 
> adding `__attribute__((overloadable))` to the declaration, which allows 
> C++-style overloading based on parameter types even when compiling in C. So 
> when the user invokes an MVE intrinsic by its 

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:121
+// Load one vector (scalar base)
+def SVLD1   : MInst<"svld1[_{2}]", "dPc", "csilUcUsUiUlhfd", [IsLoad]>;

SjoerdMeijer wrote:
> sdesmalen wrote:
> > SjoerdMeijer wrote:
> > > This encoding, e.g, this is  "csilUcUsUiUlhfd", is such a monstrosity. 
> > > It's a very efficient encoding, but of course completely unreadable.  I 
> > > know there is prior art, and know that this is how it's been done, but 
> > > just curious if you have given it thoughts how to do this in a normal 
> > > way, a bit more c++y.  I don't want to de-rail this work, but if we are 
> > > adding a new emitter, perhaps now is the time to give it a thought, so 
> > > was just curious.  
> > Haha, its a bit of a monstrosity indeed. The only thing I can think of here 
> > would be having something like:
> > ```class TypeSpecs val> {
> >   list v = val;
> > }
> > def All_Int_Float_Ty : TypeSpecs<["c", "s", "i", "l", "Uc", "Us", "Ul", 
> > "h", "f", "d">;
> > 
> > def SVLD1 : Minst<"svld1[_{2}]", "dPc", All_Int_Float_Ty, [IsLoad]>;```
> > 
> > But I suspect this gets a bit awkward because of the many permutations, I 
> > count more than 40. Not sure if that would really improve the readability.
> I would personally welcome any improvement here, even the smallest. But if 
> you think it's tricky, then fair enough!
> 
> I've managed to completely ignore the MVE intrinsics work so far, but 
> understood there were some innovations here and there (e.g. in tablegen). 
> Probably because it is dealing with similar problems: a lot of intrinsics, 
> some of them overloaded with different types. I'm going to have a little look 
> now to see if there's anything we can borrow from that, or if that is 
> unrelated
In the MVE intrinsics implementation I completely avoided that entire system of 
string-based type specifications. There's another completely different way you 
can set up the types of builtins, and I used that instead.

You can declare the function for `Builtins.def` purposes with no type 
specification at all, and then you fill in its type signature using a 
declaration in the //header file//, with the unusual combination of 
`__inline__` and no function body:
```static __inline__ int32x4_t __builtin_arm_foo_bar(int16x8_t, float23x7t); // 
or whatever```

In fact I went one step further: the user-facing names for the MVE intrinsics 
are declared in `arm_mve.h` with a special attribute indicating that they're 
aliases for clang builtins. And the MVE polymorphic intrinsics are done by 
adding `__attribute__((overloadable))` to the declaration, which allows 
C++-style overloading based on parameter types even when compiling in C. So 
when the user invokes an MVE intrinsic by its polymorphic name, the compiler 
first does overload resolution to decide which declaration in the header file 
to select; then it looks at the builtin-alias attribute and discovers which 
internal builtin id it corresponds to; and then it can do codegen for that 
builtin directly, without a wrapper function in the header.

Pros of doing it this way:
 - if the builtin requires some of its arguments to be compile-time constants, 
then you don't run into the problem that a wrapper function in the header fails 
to pass through the constantness. (In NEON this is worked around by making some 
wrapper functions be wrapper macros instead – but NEON doesn't have to deal 
with polymorphism.)
 - declaring a builtin's type signature in the header file means that it can 
include definitions that the header file has created beforehand. For example, 
one of the arguments to the MVE `vld2q` family involves a small `struct` 
containing 2 or 4 vectors, and it would be tricky to get that struct type into 
the `Builtins.def` type specification before the header file can tell clang it 
exists.
 - doing polymorphism like this, rather than making the polymorphic function be 
a macro expanding to something involving C11 `_Generic`, means the error 
messages are orders of magnitude more friendly when the user messes up a call. 
(Also it's remarkably fiddly to use `_Generic` in complicated cases, because of 
the requirement that even its untaken branches not provoke any type-checking or 
semantic errors.)
 - I don't know of any way that the preprocessor + `_Generic` approach can 
avoid expanding its macro arguments at least twice. It can avoid //evaluating// 
twice, so that's safe in the side-effect sense, but you still have the problem 
that you get exponential inflation of the size of preprocessed output if calls 
to these macros are lexically nested too deeply.

Cons:
 - you have to do all of your codegen inside the clang binary, starting from 
the function operands you're given, and ending up with LLVM IR. You don't get 
to do the tedious parts (like unpacking structs, or dereferencing pointer 
arguments for passed-by-reference parameters) in the wrapper function 

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a subscriber: simon_tatham.
SjoerdMeijer added a comment.

Adding @simon_tatham in case he feels wants to have a look too.


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:121
+// Load one vector (scalar base)
+def SVLD1   : MInst<"svld1[_{2}]", "dPc", "csilUcUsUiUlhfd", [IsLoad]>;

sdesmalen wrote:
> SjoerdMeijer wrote:
> > This encoding, e.g, this is  "csilUcUsUiUlhfd", is such a monstrosity. It's 
> > a very efficient encoding, but of course completely unreadable.  I know 
> > there is prior art, and know that this is how it's been done, but just 
> > curious if you have given it thoughts how to do this in a normal way, a bit 
> > more c++y.  I don't want to de-rail this work, but if we are adding a new 
> > emitter, perhaps now is the time to give it a thought, so was just curious. 
> >  
> Haha, its a bit of a monstrosity indeed. The only thing I can think of here 
> would be having something like:
> ```class TypeSpecs val> {
>   list v = val;
> }
> def All_Int_Float_Ty : TypeSpecs<["c", "s", "i", "l", "Uc", "Us", "Ul", "h", 
> "f", "d">;
> 
> def SVLD1 : Minst<"svld1[_{2}]", "dPc", All_Int_Float_Ty, [IsLoad]>;```
> 
> But I suspect this gets a bit awkward because of the many permutations, I 
> count more than 40. Not sure if that would really improve the readability.
I would personally welcome any improvement here, even the smallest. But if you 
think it's tricky, then fair enough!

I've managed to completely ignore the MVE intrinsics work so far, but 
understood there were some innovations here and there (e.g. in tablegen). 
Probably because it is dealing with similar problems: a lot of intrinsics, some 
of them overloaded with different types. I'm going to have a little look now to 
see if there's anything we can borrow from that, or if that is unrelated



Comment at: clang/utils/TableGen/SveEmitter.cpp:64
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())

sdesmalen wrote:
> SjoerdMeijer wrote:
> > why a default of 128? Will this gives problems for SVE implementions with> 
> > 128 bits?
> SVE vectors are n x 128bits, so the 128 is scalable here.
ah, okay, fair enough, didn't realise that.


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:121
+// Load one vector (scalar base)
+def SVLD1   : MInst<"svld1[_{2}]", "dPc", "csilUcUsUiUlhfd", [IsLoad]>;

SjoerdMeijer wrote:
> This encoding, e.g, this is  "csilUcUsUiUlhfd", is such a monstrosity. It's a 
> very efficient encoding, but of course completely unreadable.  I know there 
> is prior art, and know that this is how it's been done, but just curious if 
> you have given it thoughts how to do this in a normal way, a bit more c++y.  
> I don't want to de-rail this work, but if we are adding a new emitter, 
> perhaps now is the time to give it a thought, so was just curious.  
Haha, its a bit of a monstrosity indeed. The only thing I can think of here 
would be having something like:
```class TypeSpecs val> {
  list v = val;
}
def All_Int_Float_Ty : TypeSpecs<["c", "s", "i", "l", "Uc", "Us", "Ul", "h", 
"f", "d">;

def SVLD1 : Minst<"svld1[_{2}]", "dPc", All_Int_Float_Ty, [IsLoad]>;```

But I suspect this gets a bit awkward because of the many permutations, I count 
more than 40. Not sure if that would really improve the readability.



Comment at: clang/utils/TableGen/SveEmitter.cpp:64
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())

SjoerdMeijer wrote:
> why a default of 128? Will this gives problems for SVE implementions with> 
> 128 bits?
SVE vectors are n x 128bits, so the 128 is scalable here.



Comment at: clang/utils/TableGen/SveEmitter.cpp:119
+class Intrinsic {
+  /// The Record this intrinsic was created from.
+  Record *R;

SjoerdMeijer wrote:
> nit: for readability, perhaps don't abbreviate some of these member names? 
> 
>  R -> Record
>  BaseTS -> BaseTypeSpec
>  CK -> ClassKind
`Record` and `ClassKind` are also the names of the enum though.
Perhaps I can rename CK to `Class`?



Comment at: clang/utils/TableGen/SveEmitter.cpp:267
+switch (ElementBitwidth) {
+case 16: Base = (unsigned)SVETypeFlags::Float16; break;
+case 32: Base = (unsigned)SVETypeFlags::Float32; break;

SjoerdMeijer wrote:
> just a return here 
Good catch!


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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen updated this revision to Diff 248432.
sdesmalen marked 11 inline comments as done.
sdesmalen added a comment.

- Renamed CK and BaseTS
- Refactored switch statementsd in SVEType::getTypeFlags()


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

https://reviews.llvm.org/D75470

Files:
  clang/include/clang/Basic/AArch64SVETypeFlags.h
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/include/clang/Basic/BuiltinsSVE.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -92,6 +92,8 @@
 void EmitNeonTest2(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitSveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveCodeGenMap(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -71,6 +71,8 @@
   GenArmMveBuiltinCG,
   GenArmMveBuiltinAliases,
   GenArmSveHeader,
+  GenArmSveBuiltins,
+  GenArmSveCodeGenMap,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -183,6 +185,10 @@
"Generate ARM NEON tests for clang"),
 clEnumValN(GenArmSveHeader, "gen-arm-sve-header",
"Generate arm_sve.h for clang"),
+clEnumValN(GenArmSveBuiltins, "gen-arm-sve-builtins",
+   "Generate arm_sve_builtins.inc for clang"),
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -357,6 +363,12 @@
   case GenArmSveHeader:
 EmitSveHeader(Records, OS);
 break;
+  case GenArmSveBuiltins:
+EmitSveBuiltins(Records, OS);
+break;
+  case GenArmSveCodeGenMap:
+EmitSveCodeGenMap(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -29,6 +29,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 
 #include 
 #include 
@@ -36,12 +37,201 @@
 
 using namespace llvm;
 
-//===--===//
-// SVEEmitter
-//===--===//
+enum ClassKind {
+  ClassNone,
+  ClassS, // signed/unsigned, e.g., "_s8", "_u8" suffix
+  ClassG, // Overloaded name without type suffix
+};
+
+using TypeSpec = std::string;
+using SVETypeFlags = clang::SVETypeFlags;
 
 namespace {
 
+class SVEType {
+  TypeSpec TS;
+  bool Float, Signed, Immediate, Void, Constant, Pointer;
+  bool DefaultType, IsScalable, Predicate, PredicatePattern, PrefetchOp;
+  unsigned Bitwidth, ElementBitwidth, NumVectors;
+
+public:
+  SVEType() : SVEType(TypeSpec(), 'v') {}
+
+  SVEType(TypeSpec TS, char CharMod)
+  : TS(TS), Float(false), Signed(true), Immediate(false), Void(false),
+Constant(false), Pointer(false), DefaultType(false), IsScalable(true),
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())
+  applyTypespec();
+applyModifier(CharMod);
+  }
+
+  /// Return the value in SVETypeFlags for this type.
+  unsigned getTypeFlags() const;
+
+  bool isPointer() const { return Pointer; }
+  bool isVoidPointer() const { return Pointer && Void; }
+  bool isSigned() const { return Signed; }
+  bool isImmediate() const { return Immediate; }
+  bool isScalar() const { return NumVectors == 0; }
+  bool isVector() const { return NumVectors > 0; }
+  bool isScalableVector() const { return isVector() && IsScalable; }
+  bool isChar() const { return ElementBitwidth == 8; }
+  bool isVoid() const { return Void & !Pointer; }
+  bool isDefault() const { return DefaultType; }
+  bool isFloat() const { return Float; 

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

Big patch, I only did a first scan, but looks very reasonable in general. Just 
a first round of nits and 2 questions.




Comment at: clang/include/clang/Basic/arm_sve.td:121
+// Load one vector (scalar base)
+def SVLD1   : MInst<"svld1[_{2}]", "dPc", "csilUcUsUiUlhfd", [IsLoad]>;

This encoding, e.g, this is  "csilUcUsUiUlhfd", is such a monstrosity. It's a 
very efficient encoding, but of course completely unreadable.  I know there is 
prior art, and know that this is how it's been done, but just curious if you 
have given it thoughts how to do this in a normal way, a bit more c++y.  I 
don't want to de-rail this work, but if we are adding a new emitter, perhaps 
now is the time to give it a thought, so was just curious.  



Comment at: clang/utils/TableGen/SveEmitter.cpp:1
 //===- SveEmitter.cpp - Generate arm_sve.h for use with clang -*- C++ -*-===//
 //

I wanted to add the nit that SveEmiiter.cpp should perhaps be SVEEmitter.cpp, 
but then I saw at the bottom that MVE is spelled Mve, so perhaps this is fine 
then.



Comment at: clang/utils/TableGen/SveEmitter.cpp:64
+Predicate(false), PredicatePattern(false), PrefetchOp(false),
+Bitwidth(128), ElementBitwidth(~0U), NumVectors(1) {
+if (!TS.empty())

why a default of 128? Will this gives problems for SVE implementions with> 128 
bits?



Comment at: clang/utils/TableGen/SveEmitter.cpp:119
+class Intrinsic {
+  /// The Record this intrinsic was created from.
+  Record *R;

nit: for readability, perhaps don't abbreviate some of these member names? 

 R -> Record
 BaseTS -> BaseTypeSpec
 CK -> ClassKind



Comment at: clang/utils/TableGen/SveEmitter.cpp:263
+unsigned SVEType::getTypeFlags() const {
+  unsigned Base = 0;
+

don't need this



Comment at: clang/utils/TableGen/SveEmitter.cpp:267
+switch (ElementBitwidth) {
+case 16: Base = (unsigned)SVETypeFlags::Float16; break;
+case 32: Base = (unsigned)SVETypeFlags::Float32; break;

just a return here 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen created this revision.
sdesmalen added reviewers: efriedma, rovka, SjoerdMeijer, rsandifo-arm.
Herald added subscribers: psnobl, rkruppe, mgrang, kristof.beyls, tschuett, 
mgorny.
Herald added a reviewer: rengolin.
Herald added a project: clang.
sdesmalen added a parent revision: D75298: [Clang][SVE] Parse builtin type 
string for scalable vectors.
sdesmalen marked an inline comment as done.
sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/AArch64SVETypeFlags.h:1
+//===- SveEmitter.cpp - Generate arm_sve.h for use with clang -*- C++ -*-===//
+//

I just see that this comment will need updating, as that line seems copied from 
SveEmitter.cpp.


This is a first patch in a series for the SveEmitter to generate the arm_sve.h
header file and builtins.

I've tried my best to strip down this patch as best as I could, but there
are still a few changes that are not necessarily exercised by the load 
intrinsics
in this patch, mostly around the SVEType class which has some common logic to
represent types from a type and prototype string. I thought it didn't make
much sense to remove that from this patch and split it up.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75470

Files:
  clang/include/clang/Basic/AArch64SVETypeFlags.h
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/include/clang/Basic/BuiltinsSVE.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -92,6 +92,8 @@
 void EmitNeonTest2(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitSveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSveCodeGenMap(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -71,6 +71,8 @@
   GenArmMveBuiltinCG,
   GenArmMveBuiltinAliases,
   GenArmSveHeader,
+  GenArmSveBuiltins,
+  GenArmSveCodeGenMap,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -183,6 +185,10 @@
"Generate ARM NEON tests for clang"),
 clEnumValN(GenArmSveHeader, "gen-arm-sve-header",
"Generate arm_sve.h for clang"),
+clEnumValN(GenArmSveBuiltins, "gen-arm-sve-builtins",
+   "Generate arm_sve_builtins.inc for clang"),
+clEnumValN(GenArmSveCodeGenMap, "gen-arm-sve-codegenmap",
+   "Generate arm_sve_codegenmap.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -357,6 +363,12 @@
   case GenArmSveHeader:
 EmitSveHeader(Records, OS);
 break;
+  case GenArmSveBuiltins:
+EmitSveBuiltins(Records, OS);
+break;
+  case GenArmSveCodeGenMap:
+EmitSveCodeGenMap(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -29,6 +29,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/Error.h"
+#include "clang/Basic/AArch64SVETypeFlags.h"
 #include 
 #include 
 #include 
@@ -36,12 +37,201 @@
 
 using namespace llvm;
 
-//===--===//
-// SVEEmitter
-//===--===//
+enum ClassKind {
+  ClassNone,
+  ClassS, // signed/unsigned, e.g., "_s8", "_u8" suffix
+  ClassG, // Overloaded name without type suffix
+};
+
+using TypeSpec = std::string;
+using SVETypeFlags = clang::SVETypeFlags;
 
 namespace {
 
+class SVEType {
+  TypeSpec TS;
+  bool Float, Signed, Immediate, Void, Constant, Pointer;
+  bool DefaultType, IsScalable, Predicate, PredicatePattern, PrefetchOp;
+  unsigned Bitwidth, ElementBitwidth, NumVectors;
+
+public:
+  SVEType() : SVEType(TypeSpec(), 'v') {}
+
+  SVEType(TypeSpec TS, char CharMod)
+  : TS(TS), Float(false), Signed(true), Immediate(false), Void(f

[PATCH] D75470: [SVE] Auto-generate builtins and header for svld1.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen marked an inline comment as done.
sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/AArch64SVETypeFlags.h:1
+//===- SveEmitter.cpp - Generate arm_sve.h for use with clang -*- C++ -*-===//
+//

I just see that this comment will need updating, as that line seems copied from 
SveEmitter.cpp.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75470



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