[PATCH] D50771: [clang-tblgen] Add -print-records and -dump-json modes.

2018-08-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added a reviewer: nhaehnle.
Herald added a subscriber: cfe-commits.

Currently, if clang-tblgen is run without a mode option, it defaults
to the first mode in its 'enum Action', which happens to be
-gen-clang-attr-classes. I think it makes more sense for it to behave
the same way as llvm-tblgen, i.e. print a diagnostic dump if it's not
given any more specific instructions.

I've also added the same -dump-json that llvm-tblgen supports. This
means any tblgen command line (whether llvm- or clang-) can be
mechanically turned into one that processes the same input into JSON.


Repository:
  rC Clang

https://reviews.llvm.org/D50771

Files:
  utils/TableGen/TableGen.cpp


Index: utils/TableGen/TableGen.cpp
===
--- utils/TableGen/TableGen.cpp
+++ utils/TableGen/TableGen.cpp
@@ -23,6 +23,8 @@
 using namespace clang;
 
 enum ActionType {
+  PrintRecords,
+  DumpJSON,
   GenClangAttrClasses,
   GenClangAttrParserStringSwitches,
   GenClangAttrSubjectMatchRulesParserStringSwitches,
@@ -66,6 +68,10 @@
 cl::opt Action(
 cl::desc("Action to perform:"),
 cl::values(
+clEnumValN(PrintRecords, "print-records",
+   "Print all records to stdout (default)"),
+clEnumValN(DumpJSON, "dump-json",
+   "Dump all records as machine-readable JSON"),
 clEnumValN(GenClangAttrClasses, "gen-clang-attr-classes",
"Generate clang attribute clases"),
 clEnumValN(GenClangAttrParserStringSwitches,
@@ -164,6 +170,12 @@
 
 bool ClangTableGenMain(raw_ostream &OS, RecordKeeper &Records) {
   switch (Action) {
+  case PrintRecords:
+OS << Records;   // No argument, dump all contents
+break;
+  case DumpJSON:
+EmitJSON(Records, OS);
+break;
   case GenClangAttrClasses:
 EmitClangAttrClass(Records, OS);
 break;


Index: utils/TableGen/TableGen.cpp
===
--- utils/TableGen/TableGen.cpp
+++ utils/TableGen/TableGen.cpp
@@ -23,6 +23,8 @@
 using namespace clang;
 
 enum ActionType {
+  PrintRecords,
+  DumpJSON,
   GenClangAttrClasses,
   GenClangAttrParserStringSwitches,
   GenClangAttrSubjectMatchRulesParserStringSwitches,
@@ -66,6 +68,10 @@
 cl::opt Action(
 cl::desc("Action to perform:"),
 cl::values(
+clEnumValN(PrintRecords, "print-records",
+   "Print all records to stdout (default)"),
+clEnumValN(DumpJSON, "dump-json",
+   "Dump all records as machine-readable JSON"),
 clEnumValN(GenClangAttrClasses, "gen-clang-attr-classes",
"Generate clang attribute clases"),
 clEnumValN(GenClangAttrParserStringSwitches,
@@ -164,6 +170,12 @@
 
 bool ClangTableGenMain(raw_ostream &OS, RecordKeeper &Records) {
   switch (Action) {
+  case PrintRecords:
+OS << Records;   // No argument, dump all contents
+break;
+  case DumpJSON:
+EmitJSON(Records, OS);
+break;
   case GenClangAttrClasses:
 EmitClangAttrClass(Records, OS);
 break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47476: Support __iso_volatile_load8 etc on aarch64-win32.

2018-05-29 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
Herald added a reviewer: javed.absar.
Herald added subscribers: cfe-commits, kristof.beyls.

These intrinsics are used by MSVC's header files on AArch64 Windows as
well as AArch32, so we should support them for both targets. I've
factored them out of CodeGenFunction::EmitARMBuiltinExpr into separate
functions that EmitAArch64BuiltinExpr can call as well.


Repository:
  rC Clang

https://reviews.llvm.org/D47476

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CodeGenFunction.h
  test/CodeGen/ms-volatile-aarch64.c

Index: test/CodeGen/ms-volatile-aarch64.c
===
--- /dev/null
+++ test/CodeGen/ms-volatile-aarch64.c
@@ -0,0 +1,13 @@
+// REQUIRES: aarch64-registered-target
+// RUN: %clang_cc1 -triple aarch64-win32 -emit-llvm -fms-extensions -fms-volatile -o - < %s | FileCheck %s
+
+void test1(int volatile *p, int v) {
+  __iso_volatile_store32(p, v);
+  // CHECK-LABEL: @test1
+  // CHECK: store volatile {{.*}}, {{.*}}
+}
+int test2(const int volatile *p) {
+  return __iso_volatile_load32(p);
+  // CHECK-LABEL: @test2
+  // CHECK: load volatile {{.*}}
+}
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -3541,6 +3541,10 @@
  SmallVectorImpl &Ops,
  Address PtrOp0, Address PtrOp1,
  llvm::Triple::ArchType Arch);
+
+  llvm::Value *EmitISOVolatileLoad(const CallExpr *E);
+  llvm::Value *EmitISOVolatileStore(const CallExpr *E);
+
   llvm::Function *LookupNeonLLVMIntrinsic(unsigned IntrinsicID,
   unsigned Modifier, llvm::Type *ArgTy,
   const CallExpr *E);
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -5179,6 +5179,34 @@
   return true;
 }
 
+Value *CodeGenFunction::EmitISOVolatileLoad(const CallExpr *E) {
+  Value *Ptr = EmitScalarExpr(E->getArg(0));
+  QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+  CharUnits LoadSize = getContext().getTypeSizeInChars(ElTy);
+  llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+   LoadSize.getQuantity() * 8);
+  Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+  llvm::LoadInst *Load =
+Builder.CreateAlignedLoad(Ptr, LoadSize);
+  Load->setVolatile(true);
+  return Load;
+}
+
+Value *CodeGenFunction::EmitISOVolatileStore(const CallExpr *E) {
+  Value *Ptr = EmitScalarExpr(E->getArg(0));
+  Value *Value = EmitScalarExpr(E->getArg(1));
+  QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+  CharUnits StoreSize = getContext().getTypeSizeInChars(ElTy);
+  llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+   StoreSize.getQuantity() * 8);
+  Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+  llvm::StoreInst *Store =
+Builder.CreateAlignedStore(Value, Ptr,
+   StoreSize);
+  Store->setVolatile(true);
+  return Store;
+}
+
 Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned BuiltinID,
const CallExpr *E,
llvm::Triple::ArchType Arch) {
@@ -5421,35 +5449,13 @@
   case ARM::BI__iso_volatile_load8:
   case ARM::BI__iso_volatile_load16:
   case ARM::BI__iso_volatile_load32:
-  case ARM::BI__iso_volatile_load64: {
-Value *Ptr = EmitScalarExpr(E->getArg(0));
-QualType ElTy = E->getArg(0)->getType()->getPointeeType();
-CharUnits LoadSize = getContext().getTypeSizeInChars(ElTy);
-llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
- LoadSize.getQuantity() * 8);
-Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
-llvm::LoadInst *Load =
-  Builder.CreateAlignedLoad(Ptr, LoadSize);
-Load->setVolatile(true);
-return Load;
-  }
+  case ARM::BI__iso_volatile_load64:
+return EmitISOVolatileLoad(E);
   case ARM::BI__iso_volatile_store8:
   case ARM::BI__iso_volatile_store16:
   case ARM::BI__iso_volatile_store32:
-  case ARM::BI__iso_volatile_store64: {
-Value *Ptr = EmitScalarExpr(E->getArg(0));
-Value *Value = EmitScalarExpr(E->getArg(1));
-QualType ElTy = E->getArg(0)->getType()->getPointeeType();
-CharUnits StoreSize = getContext().getTypeSizeInChars(ElTy);
-llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
- StoreSize.getQuantity() * 8);
-Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
-llvm::StoreInst *Store =
-  Builder.CreateAlignedStore(Value, Ptr,
- S

[PATCH] D60697: [ARM] Allow "-march=foo+fp" to vary with foo.

2019-04-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, samparker, SjoerdMeijer.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls, 
javed.absar.
Herald added projects: clang, LLVM.

Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.

The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.

On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.

Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60697

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  llvm/include/llvm/Support/ARMTargetParser.h
  llvm/lib/Support/ARMTargetParser.cpp

Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -473,22 +473,68 @@
   return StringRef();
 }
 
-StringRef ARM::getArchExtFeature(StringRef ArchExt) {
-  if (ArchExt.startswith("no")) {
-StringRef ArchExtBase(ArchExt.substr(2));
-for (const auto AE : ARCHExtNames) {
-  if (AE.NegFeature && ArchExtBase == AE.getName())
-return StringRef(AE.NegFeature);
-}
+static bool wasNegated(StringRef &Name) {
+  if (Name.startswith("no")) {
+Name = Name.substr(2);
+return true;
   }
+  return false;
+}
+
+StringRef ARM::getArchExtFeature(StringRef ArchExt) {
+  bool Negated = wasNegated(ArchExt);
   for (const auto AE : ARCHExtNames) {
 if (AE.Feature && ArchExt == AE.getName())
-  return StringRef(AE.Feature);
+  return StringRef(Negated ? AE.NegFeature : AE.Feature);
   }
 
   return StringRef();
 }
 
+bool ARM::appendArchExtFeatures(
+  StringRef CPU, ARM::ArchKind AK, StringRef ArchExt,
+  std::vector &Features) {
+  StringRef StandardFeature = getArchExtFeature(ArchExt);
+  if (!StandardFeature.empty()) {
+Features.push_back(StandardFeature);
+return true;
+  }
+
+  bool Negated = wasNegated(ArchExt);
+  if (ArchExt == "fp" || ArchExt == "fp.dp") {
+unsigned FPUKind;
+if (Negated) {
+  FPUKind = ARM::FK_NONE;
+} else {
+  FPUKind = getDefaultFPU(CPU, AK);
+  if (FPUKind == ARM::FK_NONE)
+return false;
+  if (ArchExt == "fp.dp") {
+// Enable a double-precision-capable FPU in cases where the
+// default one is single-precision only.
+const FPUName &DefaultFPU = FPUNames[FPUKind];
+if (DefaultFPU.Restriction != FPURestriction::SP_D16)
+  return false;// meaningless for this arch
+
+FPUKind = ARM::FK_INVALID;
+for (const FPUName &CandidateFPU : FPUNames) {
+  if (CandidateFPU.FPUVer == DefaultFPU.FPUVer &&
+  CandidateFPU.NeonSupport == DefaultFPU.NeonSupport &&
+  CandidateFPU.Restriction == FPURestriction::D16) {
+FPUKind = CandidateFPU.ID;
+break;
+  }
+}
+  }
+}
+if (FPUKind == ARM::FK_INVALID)
+  return false;
+return ARM::getFPUFeatures(FPUKind, Features);
+  }
+
+  return false;
+}
+
 StringRef ARM::getHWDivName(unsigned HWDivKind) {
   for (const auto D : HWDivNames) {
 if (HWDivKind == D.ID)
Index: llvm/include/llvm/Support/ARMTargetParser.h
===
--- llvm/include/llvm/Support/ARMTargetParser.h
+++ llvm/include/llvm/Support/ARMTargetParser.h
@@ -233,6 +233,8 @@
 StringRef getSubArch(ArchKind AK);
 StringRef getArchExtName(unsigned ArchExtKind);
 StringRef getArchExtFeature(StringRef ArchExt);
+bool appendArchExtFeatures(StringRef CPU, ARM::ArchKind AK, StringRef ArchExt,
+   std::vector &Features);
 StringRef getHWDivName(unsigned HWDivKind);
 
 // Information by Name
Index: clang/lib/Driver

[PATCH] D60699: [ARM] add CLI support for 8.1-M and MVE.

2019-04-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, samparker, SjoerdMeijer.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

Given the existing infrastructure in LLVM side for +fp and +fp.dp,
this is more or less trivial, needing only one tiny source change and
a couple of tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60699

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/test/Driver/armv8.1m.main.c
  clang/test/Driver/armv8.1m.main.s

Index: clang/test/Driver/armv8.1m.main.s
===
--- /dev/null
+++ clang/test/Driver/armv8.1m.main.s
@@ -0,0 +1,65 @@
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V8M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+dsp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_DSP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp.dp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve+fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
+# RUN: %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp %s
+
+.syntax unified
+.thumb
+.text
+
+csinc r0, r1, r2, eq
+# ERROR-V8M: :[[@LINE-1]]:1: error
+
+qadd r0, r1, r2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_FP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-4]]:1: error
+
+vadd.f16 s0, s1, s2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
+
+vabs.f32 s0, s1
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
+
+vcmp.f64 d0,d1
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-5]]:1: error
+# ERROR-V81M_MVE_FP: :[[@LINE-6]]:1: error
+# ERROR-V81M_MVEFP: :[[@LINE-7]]:1: error
+
+asrl r0, r1, r2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
+
+vcadd.i8 q0, q1, q2, #90
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
Index: clang/test/Driver/armv8.1m.main.c
===
--- /dev/null
+++ clang/test/Driver/armv8.1m.main.c
@@ -0,0 +1,34 @@
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+dsp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-DSP < %t %s
+// CHECK-DSP: "-target-feature" "+dsp"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-FP < %t %s
+// CHECK-FP: "-target-feature" "+fp-armv8"
+// CHECK-FP-NOT: "-target-feature" "+fp64"
+// CHECK-FP-NOT: "-target-feature" "+d32"
+// CHECK-FP: "-target-feature" "+fullfp16"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp.dp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-FPDP < %t %s
+// CHECK-FPDP: "-target-feature" "+fp-armv8"
+// CHECK-FPDP: "-target-feature" "+fullfp16"
+// CHECK-FPDP: "-target-feature" "+fp64"
+// CHECK-FPDP-NOT: "-target-feature" "+d32"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVE < %t %s
+// CHECK-MVE: "-target-feature" "+mve"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVEFP < %t %s
+// CHECK-MVEFP: "-target-feature" "+mve.fp"
+// CHECK-MVEFP-NOT: "-target-feature" "+fp64"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVEFP_DP < %t %s
+// CHECK-MVEFP_DP: "-target-feature" "+mve.fp"
+// CHECK-MVEFP_DP: "-target-feature" "+fp64"
+
+// RUN: %clang -target arm-arm-none-eabi -marc

[PATCH] D60709: [ARM] Support inline assembler constraints for MVE.

2019-04-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, samparker, SjoerdMeijer.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls, 
eraman, javed.absar.
Herald added projects: clang, LLVM.

"To" selects an odd-numbered GPR, and "Te" an even one. There are some
8.1-M instructions that have one too few bits in their register fields
and require registers of particular parity, without necessarily using
a consecutive even/odd pair.

Also, the constraint letter "t" should select an MVE q-register, when
MVE is present. This didn't need any source changes, but some extra
tests have been added.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60709

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/test/CodeGen/arm-asm.c
  llvm/docs/LangRef.rst
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
  llvm/test/CodeGen/ARM/inlineasm-mve.ll
  llvm/test/CodeGen/ARM/inlineasm.ll

Index: llvm/test/CodeGen/ARM/inlineasm.ll
===
--- llvm/test/CodeGen/ARM/inlineasm.ll
+++ llvm/test/CodeGen/ARM/inlineasm.ll
@@ -48,3 +48,27 @@
 	%0 = tail call <4 x float> asm "vadd.f32 $0, $1, $2", "=t,t,t"(<4 x float> %a, <4 x float> %b)
 	ret <4 x float> %0
 }
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"(i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^To,=^To,=^To,=^To,0,1,2,3"(i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
Index: llvm/test/CodeGen/ARM/inlineasm-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/inlineasm-mve.ll
@@ -0,0 +1,48 @@
+; RUN: llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o - | FileCheck %s
+
+define i32 @test1(i32 %tmp54) {
+	%tmp56 = tail call i32 asm "uxtb16 $0,$1", "=r,r"( i32 %tmp54 )
+	ret i32 %tmp56
+}
+
+define void @test2() {
+	tail call void asm sideeffect "/* number: ${0:c} */", "i"( i32 1 )
+	ret void
+}
+
+define <4 x i32> @mve-t-constraint-128bit(<4 x i32>, <4 x i32>) {
+; CHECK-LABEL: mve-t-constraint-128bit
+; CHECK: vadd.i32 q{{[0-7]}}, q{{[0-7]}}, q{{[0-7]}}
+  %ret = tail call <4 x i32>
+ asm "vadd.i32 $0, $1, $2", "=t,t,t"
+ (<4 x i32> %0, <4 x i32> %1)
+  ret <4 x i32> %ret
+}
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^To,=^To,=^To,=^To,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
Index: llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
@@ -0,0 +1,14 @@
+; RUN: not llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o /dev/null 2>&1 | FileCheck %s
+
+; CHECK: inline assembly requires more registers than available
+define <4 x i32> @t-constraint-i32-vectors-too-few-regs(<4 x i32> %a, <4 x i32> %b) {
+entry:
+	%0 = tail call { <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+ <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32> }
+   asm "

[PATCH] D60710: [ARM] Add ACLE feature macros for MVE.

2019-04-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, samparker, SjoerdMeijer.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined
to a value which has bit 0 set for integer MVE, and bit 1 set for
floating-point MVE.

(Floating-point MVE implies integer MVE, so if this macro is defined
at all then it will be set to 1 or 3, never 2.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60710

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h


Index: clang/lib/Basic/Targets/ARM.h
===
--- clang/lib/Basic/Targets/ARM.h
+++ clang/lib/Basic/Targets/ARM.h
@@ -33,6 +33,11 @@
 FPARMV8 = (1 << 4)
   };
 
+  enum MVEMode {
+  MVE_INT = (1 << 0),
+  MVE_FP  = (1 << 1)
+  };
+
   // Possible HWDiv features.
   enum HWDivMode { HWDivThumb = (1 << 0), HWDivARM = (1 << 1) };
 
@@ -56,6 +61,7 @@
   unsigned ArchVersion;
 
   unsigned FPU : 5;
+  unsigned MVE : 2;
 
   unsigned IsAAPCS : 1;
   unsigned HWDiv : 2;
@@ -100,6 +106,8 @@
   bool isThumb() const;
   bool supportsThumb() const;
   bool supportsThumb2() const;
+  bool hasMVE() const;
+  bool hasMVEFloat() const;
 
   StringRef getCPUAttr() const;
   StringRef getCPUProfile() const;
Index: clang/lib/Basic/Targets/ARM.cpp
===
--- clang/lib/Basic/Targets/ARM.cpp
+++ clang/lib/Basic/Targets/ARM.cpp
@@ -146,6 +146,14 @@
   }
 }
 
+bool ARMTargetInfo::hasMVE() const {
+  return ArchKind == llvm::ARM::ArchKind::ARMV8_1MMainline && MVE != 0;
+}
+
+bool ARMTargetInfo::hasMVEFloat() const {
+  return hasMVE() && (MVE & MVE_FP);
+}
+
 bool ARMTargetInfo::isThumb() const {
   return ArchISA == llvm::ARM::ISAKind::THUMB;
 }
@@ -443,6 +451,13 @@
   HasLegalHalfType = true;
 } else if (Feature == "+dotprod") {
   DotProd = true;
+} else if (Feature == "+mve") {
+  DSP = 1;
+  MVE |= MVE_INT;
+} else if (Feature == "+mve.fp") {
+  DSP = 1;
+  MVE |= MVE_INT | MVE_FP;
+  HW_FP |= HW_FP_SP | HW_FP_HP;
 }
   }
 
@@ -493,6 +508,7 @@
   .Case("vfp", FPU && !SoftFloat)
   .Case("hwdiv", HWDiv & HWDivThumb)
   .Case("hwdiv-arm", HWDiv & HWDivARM)
+  .Case("mve", hasMVE())
   .Default(false);
 }
 
@@ -708,6 +724,10 @@
 "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
   }
 
+  if (hasMVE()) {
+Builder.defineMacro("__ARM_FEATURE_MVE", hasMVEFloat() ? "3" : "1");
+  }
+
   Builder.defineMacro("__ARM_SIZEOF_WCHAR_T",
   Twine(Opts.WCharSize ? Opts.WCharSize : 4));
 


Index: clang/lib/Basic/Targets/ARM.h
===
--- clang/lib/Basic/Targets/ARM.h
+++ clang/lib/Basic/Targets/ARM.h
@@ -33,6 +33,11 @@
 FPARMV8 = (1 << 4)
   };
 
+  enum MVEMode {
+  MVE_INT = (1 << 0),
+  MVE_FP  = (1 << 1)
+  };
+
   // Possible HWDiv features.
   enum HWDivMode { HWDivThumb = (1 << 0), HWDivARM = (1 << 1) };
 
@@ -56,6 +61,7 @@
   unsigned ArchVersion;
 
   unsigned FPU : 5;
+  unsigned MVE : 2;
 
   unsigned IsAAPCS : 1;
   unsigned HWDiv : 2;
@@ -100,6 +106,8 @@
   bool isThumb() const;
   bool supportsThumb() const;
   bool supportsThumb2() const;
+  bool hasMVE() const;
+  bool hasMVEFloat() const;
 
   StringRef getCPUAttr() const;
   StringRef getCPUProfile() const;
Index: clang/lib/Basic/Targets/ARM.cpp
===
--- clang/lib/Basic/Targets/ARM.cpp
+++ clang/lib/Basic/Targets/ARM.cpp
@@ -146,6 +146,14 @@
   }
 }
 
+bool ARMTargetInfo::hasMVE() const {
+  return ArchKind == llvm::ARM::ArchKind::ARMV8_1MMainline && MVE != 0;
+}
+
+bool ARMTargetInfo::hasMVEFloat() const {
+  return hasMVE() && (MVE & MVE_FP);
+}
+
 bool ARMTargetInfo::isThumb() const {
   return ArchISA == llvm::ARM::ISAKind::THUMB;
 }
@@ -443,6 +451,13 @@
   HasLegalHalfType = true;
 } else if (Feature == "+dotprod") {
   DotProd = true;
+} else if (Feature == "+mve") {
+  DSP = 1;
+  MVE |= MVE_INT;
+} else if (Feature == "+mve.fp") {
+  DSP = 1;
+  MVE |= MVE_INT | MVE_FP;
+  HW_FP |= HW_FP_SP | HW_FP_HP;
 }
   }
 
@@ -493,6 +508,7 @@
   .Case("vfp", FPU && !SoftFloat)
   .Case("hwdiv", HWDiv & HWDivThumb)
   .Case("hwdiv-arm", HWDiv & HWDivARM)
+  .Case("mve", hasMVE())
   .Default(false);
 }
 
@@ -708,6 +724,10 @@
 "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
   }
 
+  if (hasMVE()) {
+Builder.defineMacro("__ARM_FEATURE_MVE", hasMVEFloat() ? "3" : "1");
+  }
+
   Builder.defineMacro("__ARM_SIZEOF_WCHAR_T",
   Twine(Opts.WCharSize ? Opts.WCharSize : 4));
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-

[PATCH] D60709: [ARM] Support inline assembler constraints for MVE.

2019-04-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Yes, it is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60709



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


[PATCH] D60697: [ARM] Allow "-march=foo+fp" to vary with foo.

2019-04-16 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 3 inline comments as done.
simon_tatham added a comment.

The aim of this change is that it will apply to the v8.1-M (mainline) 
architecture introduced in D60698 , in which 
`+fp` //won't// be the default: `-march=armv8.1m.main` by itself gives you the 
base 8.1-M architecture without any FP, `-march=armv8.1m.main+fp` gives you the 
optional single-precision FP extension on top of that, and `+fp.dp` gives you 
double precision as well.




Comment at: llvm/lib/Support/ARMTargetParser.cpp:476
 
-StringRef ARM::getArchExtFeature(StringRef ArchExt) {
-  if (ArchExt.startswith("no")) {
-StringRef ArchExtBase(ArchExt.substr(2));
-for (const auto AE : ARCHExtNames) {
-  if (AE.NegFeature && ArchExtBase == AE.getName())
-return StringRef(AE.NegFeature);
-}
+static bool wasNegated(StringRef &Name) {
+  if (Name.startswith("no")) {

t.p.northover wrote:
> I think `isNegated` is probably more in line with existing naming.
Hmmm. I thought that would be a confusing name because it hides the fact that 
the function strips off the `no` prefix. (The use of 'was' was intended to hint 
that by the time the function returns, it's not true any more!)

Perhaps `stripNegationPrefix` (returning bool to indicate success)?



Comment at: llvm/lib/Support/ARMTargetParser.cpp:504-507
+  if (ArchExt == "fp" || ArchExt == "fp.dp") {
+unsigned FPUKind;
+if (Negated) {
+  FPUKind = ARM::FK_NONE;

t.p.northover wrote:
> Doesn't this mean `+nofp.dp` disables all floats? That seems surprising 
> behaviour to me, but I can't find any existing tests covering it.
Hmmm, that's a good point. What //would// a user expect in that situation? If 
double-precision FP was the default for that architecture and a 
single-precision version existed, then perhaps `nofp.dp` should fall back to 
that, but what if it's double or nothing?



Comment at: llvm/lib/Support/ARMTargetParser.cpp:516-517
+const FPUName &DefaultFPU = FPUNames[FPUKind];
+if (DefaultFPU.Restriction != FPURestriction::SP_D16)
+  return false;// meaningless for this arch
+

t.p.northover wrote:
> Doesn't this silently disable the FPU entirely if we decide "fp.dp" is 
> useless? That seems unlikely to be what a user wants, especially without a 
> diagnostic.
> 
> Could you also expand on the comment a bit more. I had to look up exactly 
> what FPURestrictions existed to get this, and I'm not even 100% sure I'm 
> right now.
I don't think it //silently// disables it, does it? Returning false from this 
function is a failure indication that ends up back in `checkARMArchName` in 
`clang/lib/Driver/ToolChains/Arch/ARM.cpp`, which will generate a diagnostic. 
For example, if I try `-march=armv6m+fp.dp` then I see
```
error: the clang compiler does not support '-march=armv6m+fp.dp'
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60697



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-05-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: SjoerdMeijer, dmgreen.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls, 
javed.absar.
Herald added projects: clang, LLVM.

The recent change D60691  introduced a bug in 
clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.

The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694 ) `fpregs`, which also need 
to be turned off to
disable hardware FP completely.

Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62729

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/CodeGen/arm-mfpu-none.c
  llvm/lib/Support/ARMTargetParser.cpp


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -433,8 +433,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 //as well.
@@ -442,6 +442,11 @@
 "neon", "crypto", "dotprod", "fp16fml"})
   if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
 Features.push_back(Args.MakeArgString("-" + Feature));
+
+// Disable the base feature unconditionally, even if it was not
+// explicitly in the features list (e.g. if we had +vfp3, which
+// implies it).
+Features.push_back("-fpregs");
   }
 
   // En/disable crc code generation.


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -433,8 +433,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent featur

[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-05-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/test/CodeGen/arm-mfpu-none.c:2
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+

dmgreen wrote:
> lebedev.ri wrote:
> > Generally clang codegen tests should test `-emit-llvm -S` output
> Perhaps add to the tests in clang/test/Driver/arm-mfpu.c instead?
@lebedev.ri : looking at the IR doesn't show up what I'm trying to test in this 
case. And I modelled this on existing tests in test/CodeGen, such as 
`arm-eabi.c`, which also need to test the real assembler output in order to do 
their job.

@dmgreen: it's true that I could also make `test/Driver/arm-mfpu.c` check that 
the extra feature name is appearing in the cc1 command line where I currently 
think it should be, but I think that wouldn't replace this test. The real point 
of this test is that the //currently// right feature names might not stay 
right, if the feature set is reorganised again in future – and if that happens, 
then whoever does it will probably rewrite most of `arm-mfpu.c` anyway.

So this is an end-to-end check that //whatever// detailed command line is 
generated by the driver in these circumstances, it is sufficient to ensure that 
the final generated code really doesn't include FP instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/test/CodeGen/arm-mfpu-none.c:2
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+

dmgreen wrote:
> simon_tatham wrote:
> > dmgreen wrote:
> > > lebedev.ri wrote:
> > > > Generally clang codegen tests should test `-emit-llvm -S` output
> > > Perhaps add to the tests in clang/test/Driver/arm-mfpu.c instead?
> > @lebedev.ri : looking at the IR doesn't show up what I'm trying to test in 
> > this case. And I modelled this on existing tests in test/CodeGen, such as 
> > `arm-eabi.c`, which also need to test the real assembler output in order to 
> > do their job.
> > 
> > @dmgreen: it's true that I could also make `test/Driver/arm-mfpu.c` check 
> > that the extra feature name is appearing in the cc1 command line where I 
> > currently think it should be, but I think that wouldn't replace this test. 
> > The real point of this test is that the //currently// right feature names 
> > might not stay right, if the feature set is reorganised again in future – 
> > and if that happens, then whoever does it will probably rewrite most of 
> > `arm-mfpu.c` anyway.
> > 
> > So this is an end-to-end check that //whatever// detailed command line is 
> > generated by the driver in these circumstances, it is sufficient to ensure 
> > that the final generated code really doesn't include FP instructions.
> I believe that the idea is that if we test each step, so make sure we have 
> tests from clang driver -> clang-cl and clang -> llvm-ir and llvm -> asm, 
> then it should all be tested. And because each has a well defined interfaces 
> along each step of the way it should keep working. Any integration tests are 
> often left to external tests like the test suite.
> 
> But I do see some precedent for this in other places. If you add the extra 
> checks in test/Driver/arm-mfpu.c, then I think this is fine. (And I guess if 
> someone objects we can always take it out :) )
I think the shortcomings of that step-by-step testing strategy are exactly what 
caused the breakage in the first place.

If you know you're changing the mapping from driver arguments to cc1 feature 
options, then you change the test that //obviously// goes with the change you 
just made; but you leave unchanged the test that says the //previous// set of 
cc1 options caused the behaviour you wanted – because nothing will remind you 
that that needs changing as well (or make you aware that that test even exists 
to be updated, if you didn't already know).

An end-to-end test that ensures that //this// user input continues to cause 
//that// ultimate output code, regardless of the intervening details, would 
have prevented this bug arising last week, where the other strategy didn't. 
(Indeed, an end-to-end test of exactly that kind in our //downstream// tests is 
how we spotted it shortly after the change landed.)

So I still think I'd prefer not to remove this end-to-end test (though I will 
if people absolutely insist). But I'll add those extra checks you mention in 
`arm-mfpu.c`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 202681.
simon_tatham added a comment.

Added the extra checks in `arm-mfpu.c`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/CodeGen/arm-mfpu-none.c
  clang/test/Driver/arm-mfpu.c
  llvm/lib/Support/ARMTargetParser.cpp


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -430,8 +430,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 //as well.
@@ -439,6 +439,11 @@
 "neon", "crypto", "dotprod", "fp16fml"})
   if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
 Features.push_back(Args.MakeArgString("-" + Feature));
+
+// Disable the base feature unconditionally, even if it was not
+// explicitly in the features list (e.g. if we had +vfp3, which
+// implies it).
+Features.push_back("-fpregs");
   }
 
   // En/disable crc code generation.


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-register

[PATCH] D60691: [ARM] Replace fp-only-sp and d16 with fp64 and d32.

2019-06-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added a comment.

Hmm, yes, I see what you mean. It //looks// to me as if the problem is that 
`llvm::ARM::getFPUFeatures` is setting up a feature list including `+vfp4`, 
`-fp64` and `-d32` just as you'd expect, but when it's called from 
`clang::targets::ARMTargetInfo::initFeatureMap` in particular, that silently 
throws away any feature name in the list that doesn't start with `+`.

I suppose that means `getFPUFeatures` ought to be more careful, and add the 
more restricted feature `vfp4d16sp` in the first place instead of trying to do 
it by adding full `vfp4` and then taking pieces away.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60691



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


[PATCH] D62998: [ARM] Fix bugs introduced by the fp64/d32 rework.

2019-06-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, 
JamesNagurne.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls, 
javed.absar, srhines.
Herald added projects: clang, LLVM.

Change D60691  caused some knock-on failures 
that weren't caught by the
existing tests. Firstly, selecting a CPU that should have had a
restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs
and no double precision) could give the unrestricted version, because
`ARM::getFPUFeatures` returned a list of features including subtracted
ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw
away all the ones that didn't start with `+`. Secondly, the
preprocessor macros didn't reliably match the actual compilation
settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as
if hardware FP was available, because the list of features on the cc1
command line would include things like `+vfp4`,`-vfp4d16` and clang
didn't realise that one of those cancelled out the other.

I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so
that it returns a list that enables every FP-related feature
compatible with the selected FPU and disables every feature not
compatible, which is more verbose but means clang doesn't have to
understand the dependency relationships between the backend features.
Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all
the various forms of the FP feature names, so that it won't miss cases
where it should have set `HW_FP` to feed into feature test macros.

That in turn caused an ordering problem when handling `-mcpu=foo+bar`
together with `-mfpu=something_that_turns_off_bar`. To fix that, I've
arranged that the `+bar` suffixes on the end of `-mcpu` and `-march`
cause feature names to be put into a separate vector which is
concatenated after the output of `getFPUFeatures`.

Another side effect of all this is to fix a bug where `clang -target
armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even
though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was
because `HW_FP` was being set to a value including only the `FPARMV8`
bit, but that feature test macro was testing only the `VFP4FPU` bit.
Now `HW_FP` ends up with all the bits set, so it gives the right
answer.

Changes to tests included in this patch:

- `arm-target-features.c`: I had to change basically all the expected results. 
(The Cortex-M4 test in there should function as a regression test for the 
accidental double-precision bug.)
- `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so 
that those tests are no longer sensitive to the order of cc1 feature options on 
the command line.
- `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test.
- `Preprocessor/arm-target-features.c`: added a regression test for the 
`mfpu=softvfp` issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62998

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/CodeGen/arm-target-features.c
  clang/test/Driver/arm-mfpu.c
  clang/test/Driver/armv8.1m.main.c
  clang/test/Preprocessor/arm-acle-6.5.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/lib/Support/ARMTargetParser.cpp

Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -162,87 +162,63 @@
   if (FPUKind >= FK_LAST || FPUKind == FK_INVALID)
 return false;
 
-  // FPU version subtarget features are inclusive of lower-numbered ones, so
-  // enable the one corresponding to this version and disable all that are
-  // higher. We also have to make sure to disable fp16 when vfp4 is disabled,
-  // as +vfp4 implies +fp16 but -vfp4 does not imply -fp16.
-  switch (FPUNames[FPUKind].FPUVer) {
-  case FPUVersion::VFPV5_FULLFP16:
-Features.push_back("+fp-armv8");
-Features.push_back("+fullfp16");
-break;
-  case FPUVersion::VFPV5:
-Features.push_back("+fp-armv8");
-break;
-  case FPUVersion::VFPV4:
-Features.push_back("+vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV3_FP16:
-Features.push_back("+vfp3");
-Features.push_back("+fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV3:
-Features.push_back("+vfp3");
-Features.push_back("-fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV2:
-Features.push_back("+vfp2");
-Features.push_back("-vfp3");
-Features.push_back("-fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::NONE:
-Features.push_back("-fpregs");
-Features.push_back("-vfp2");
-Features.push_back("-vf

[PATCH] D62998: [ARM] Fix bugs introduced by the fp64/d32 rework.

2019-06-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 2 inline comments as done.
simon_tatham added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:449
 //as well.
-for (std::string Feature : {"vfp2", "vfp3", "vfp4", "fp-armv8", "fullfp16",
-"neon", "crypto", "dotprod", "fp16fml"})
-  if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
-Features.push_back(Args.MakeArgString("-" + Feature));
-
-// Disable the base feature unconditionally, even if it was not
-// explicitly in the features list (e.g. if we had +vfp3, which
-// implies it).
-Features.push_back("-fpregs");
+for (std::string Feature : {
+"vfp2", "vfp2sp", "vfp2d16", "vfp2d16sp",

SjoerdMeijer wrote:
> This function and this code is truly one of the worst I guess I mean, 
> it's not worse than it was before, but you'd really hope that there was a 
> (targetparser) API that gives you a list of FPUs, possibly matching some 
> criteria, rather than yet another list of hard coded strings. It gets worse, 
> this is repeated in `lib/Support/ARMTargetParser.cpp`. End of rant! ;-)
> 
> More on topic: do we need to add +mve.fp here?
It did occur to me that this code could be made a lot simpler if clang had 
direct access to the data about the dependency relations between subtarget 
features. Then it could replace all of this with a simpler and more robust set 
of tests for things like "does the transitive closure of the feature set 
include `vfp4d16sp`?" instead of having to list every individual feature that 
//might// appear. But currently that dependency web lives in the ARM target's 
tablegen, so it isn't guaranteed to be compiled in to the LLVM that clang is 
linking against.



Comment at: llvm/lib/Support/ARMTargetParser.cpp:178
+
+{"+fpregs", "-fpregs", FPUVersion::VFPV2, FPURestriction::SP_D16},
+{"+vfp2", "-vfp2", FPUVersion::VFPV2, FPURestriction::None},

SjoerdMeijer wrote:
> This looks familiar  I don't think we can easily simplify this? Or get 
> rid of? I guess that's best done in a follow up when we this working again? 
> Perhaps the only insignificant simplification is that we don't need the 
> + and - because they are the same.
As I say in the comment a few lines up, we need both versions of the string 
because this function is returning a vector of `StringRef` with no mechanism to 
free anything it allocates, so it has to return pointers to static string 
literals.

(I could do some preprocessor fiddling to expand a single feature name into 
both strings, but I tend to assume most people have a less strong stomach for 
cpp horrors than I do :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62998



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


[PATCH] D62998: [ARM] Fix bugs introduced by the fp64/d32 rework.

2019-06-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 203526.
simon_tatham added a comment.

Renamed `FeaturesAfter` to `ExtensionFeatures` and added a comment
explaining why it has to be separate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62998

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/CodeGen/arm-target-features.c
  clang/test/Driver/arm-mfpu.c
  clang/test/Driver/armv8.1m.main.c
  clang/test/Preprocessor/arm-acle-6.5.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/lib/Support/ARMTargetParser.cpp

Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -162,87 +162,63 @@
   if (FPUKind >= FK_LAST || FPUKind == FK_INVALID)
 return false;
 
-  // FPU version subtarget features are inclusive of lower-numbered ones, so
-  // enable the one corresponding to this version and disable all that are
-  // higher. We also have to make sure to disable fp16 when vfp4 is disabled,
-  // as +vfp4 implies +fp16 but -vfp4 does not imply -fp16.
-  switch (FPUNames[FPUKind].FPUVer) {
-  case FPUVersion::VFPV5_FULLFP16:
-Features.push_back("+fp-armv8");
-Features.push_back("+fullfp16");
-break;
-  case FPUVersion::VFPV5:
-Features.push_back("+fp-armv8");
-break;
-  case FPUVersion::VFPV4:
-Features.push_back("+vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV3_FP16:
-Features.push_back("+vfp3");
-Features.push_back("+fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV3:
-Features.push_back("+vfp3");
-Features.push_back("-fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::VFPV2:
-Features.push_back("+vfp2");
-Features.push_back("-vfp3");
-Features.push_back("-fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  case FPUVersion::NONE:
-Features.push_back("-fpregs");
-Features.push_back("-vfp2");
-Features.push_back("-vfp3");
-Features.push_back("-fp16");
-Features.push_back("-vfp4");
-Features.push_back("-fp-armv8");
-break;
-  }
-
-  // fp64 and d32 subtarget features are independent of each other, so we
-  // must disable/enable both.
-  if (FPUKind == FK_NONE) {
-Features.push_back("-fp64");
-Features.push_back("-d32");
-  } else {
-switch (FPUNames[FPUKind].Restriction) {
-case FPURestriction::SP_D16:
-  Features.push_back("-fp64");
-  Features.push_back("-d32");
-  break;
-case FPURestriction::D16:
-  Features.push_back("+fp64");
-  Features.push_back("-d32");
-  break;
-case FPURestriction::None:
-  Features.push_back("+fp64");
-  Features.push_back("+d32");
-  break;
-}
+  static const struct FPUFeatureNameInfo {
+const char *PlusName, *MinusName;
+FPUVersion MinVersion;
+FPURestriction MaxRestriction;
+  } FPUFeatureInfoList[] = {
+// We have to specify the + and - versions of the name in full so
+// that we can return them as static StringRefs.
+//
+// Also, the SubtargetFeatures ending in just "sp" are listed here
+// under FPURestriction::None, which is the only FPURestriction in
+// which they would be valid (since FPURestriction::SP doesn't
+// exist).
+
+{"+fpregs", "-fpregs", FPUVersion::VFPV2, FPURestriction::SP_D16},
+{"+vfp2", "-vfp2", FPUVersion::VFPV2, FPURestriction::None},
+{"+vfp2d16", "-vfp2d16", FPUVersion::VFPV2, FPURestriction::D16},
+{"+vfp2d16sp", "-vfp2d16sp", FPUVersion::VFPV2, FPURestriction::SP_D16},
+{"+vfp2sp", "-vfp2sp", FPUVersion::VFPV2, FPURestriction::None},
+{"+vfp3", "-vfp3", FPUVersion::VFPV3, FPURestriction::None},
+{"+vfp3d16", "-vfp3d16", FPUVersion::VFPV3, FPURestriction::D16},
+{"+vfp3d16sp", "-vfp3d16sp", FPUVersion::VFPV3, FPURestriction::SP_D16},
+{"+vfp3sp", "-vfp3sp", FPUVersion::VFPV3, FPURestriction::None},
+{"+fp16", "-fp16", FPUVersion::VFPV3_FP16, FPURestriction::SP_D16},
+{"+vfp4", "-vfp4", FPUVersion::VFPV4, FPURestriction::None},
+{"+vfp4d16", "-vfp4d16", FPUVersion::VFPV4, FPURestriction::D16},
+{"+vfp4d16sp", "-vfp4d16sp", FPUVersion::VFPV4, FPURestriction::SP_D16},
+{"+vfp4sp", "-vfp4sp", FPUVersion::VFPV4, FPURestriction::None},
+{"+fp-armv8", "-fp-armv8", FPUVersion::VFPV5, FPURestriction::None},
+{"+fp-armv8d16", "-fp-armv8d16", FPUVersion::VFPV5, FPURestriction::D16},
+{"+fp-armv8d16sp", "-fp-armv8d16sp", FPUVersion::VFPV5, FPURestriction::SP_D16},
+{"+fp-armv8sp", "-fp-armv8sp", FPUVersion::VFPV5, FPURestriction::None},
+{"+fullfp16", "-fullfp16", FPUVersion::VFPV5_FULLFP16, FPURestriction::SP_D16},
+{"+fp64", "-fp64"

[PATCH] D60709: [ARM] Support inline assembler constraints for MVE.

2019-06-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 204039.
simon_tatham added a comment.

Remastered patch to apply cleanly against current trunk.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60709

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/test/CodeGen/arm-asm.c
  llvm/docs/LangRef.rst
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
  llvm/test/CodeGen/ARM/inlineasm-mve.ll
  llvm/test/CodeGen/ARM/inlineasm.ll

Index: llvm/test/CodeGen/ARM/inlineasm.ll
===
--- llvm/test/CodeGen/ARM/inlineasm.ll
+++ llvm/test/CodeGen/ARM/inlineasm.ll
@@ -48,3 +48,27 @@
 	%0 = tail call <4 x float> asm "vadd.f32 $0, $1, $2", "=t,t,t"(<4 x float> %a, <4 x float> %b)
 	ret <4 x float> %0
 }
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"(i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^To,=^To,=^To,=^To,0,1,2,3"(i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
Index: llvm/test/CodeGen/ARM/inlineasm-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/inlineasm-mve.ll
@@ -0,0 +1,48 @@
+; RUN: llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o - | FileCheck %s
+
+define i32 @test1(i32 %tmp54) {
+	%tmp56 = tail call i32 asm "uxtb16 $0,$1", "=r,r"( i32 %tmp54 )
+	ret i32 %tmp56
+}
+
+define void @test2() {
+	tail call void asm sideeffect "/* number: ${0:c} */", "i"( i32 1 )
+	ret void
+}
+
+define <4 x i32> @mve-t-constraint-128bit(<4 x i32>, <4 x i32>) {
+; CHECK-LABEL: mve-t-constraint-128bit
+; CHECK: vadd.i32 q{{[0-7]}}, q{{[0-7]}}, q{{[0-7]}}
+  %ret = tail call <4 x i32>
+ asm "vadd.i32 $0, $1, $2", "=t,t,t"
+ (<4 x i32> %0, <4 x i32> %1)
+  ret <4 x i32> %ret
+}
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^To,=^To,=^To,=^To,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
Index: llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/inlineasm-error-t-toofewregs-mve.ll
@@ -0,0 +1,14 @@
+; RUN: not llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o /dev/null 2>&1 | FileCheck %s
+
+; CHECK: inline assembly requires more registers than available
+define <4 x i32> @t-constraint-i32-vectors-too-few-regs(<4 x i32> %a, <4 x i32> %b) {
+entry:
+	%0 = tail call { <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+ <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32> }
+   asm "",
+ "=t,=t,=t,=t,=t,=t,=t,=t,=t,=t,t,t"(<4 x i32> %a, <4 x i32> %b)
+	%asmresult = extractvalue { <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+<4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+<4 x i32>, <4 x i32> } %0, 0
+	ret <4 x i32> %asmresult
+}
Index: llvm/lib/Target/ARM/ARMISelLowering.cpp
=

[PATCH] D60709: [ARM] Support inline assembler constraints for MVE.

2019-06-25 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 206455.
simon_tatham added a comment.

Rebased this patch to current trunk, and also fixed a test failure by adding 
`arm_aapcs_vfpcc` to the test functions that use MVE vector types (since we 
can't support passing vector types in GPRs until we get all the operations like 
build_vector and insert_element fully supported).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60709

Files:
  clang/lib/Basic/Targets/ARM.cpp
  clang/test/CodeGen/arm-asm.c
  llvm/docs/LangRef.rst
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/test/CodeGen/ARM/inlineasm.ll
  llvm/test/CodeGen/Thumb2/inlineasm-error-t-toofewregs-mve.ll
  llvm/test/CodeGen/Thumb2/inlineasm-mve.ll

Index: llvm/test/CodeGen/Thumb2/inlineasm-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/inlineasm-mve.ll
@@ -0,0 +1,48 @@
+; RUN: llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o - | FileCheck %s
+
+define i32 @test1(i32 %tmp54) {
+	%tmp56 = tail call i32 asm "uxtb16 $0,$1", "=r,r"( i32 %tmp54 )
+	ret i32 %tmp56
+}
+
+define void @test2() {
+	tail call void asm sideeffect "/* number: ${0:c} */", "i"( i32 1 )
+	ret void
+}
+
+define arm_aapcs_vfpcc <4 x i32> @mve-t-constraint-128bit(<4 x i32>, <4 x i32>) {
+; CHECK-LABEL: mve-t-constraint-128bit
+; CHECK: vadd.i32 q{{[0-7]}}, q{{[0-7]}}, q{{[0-7]}}
+  %ret = tail call <4 x i32>
+ asm "vadd.i32 $0, $1, $2", "=t,t,t"
+ (<4 x i32> %0, <4 x i32> %1)
+  ret <4 x i32> %ret
+}
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 }
+ asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^To,=^To,=^To,=^To,0,1,2,3"
+ (i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
Index: llvm/test/CodeGen/Thumb2/inlineasm-error-t-toofewregs-mve.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb2/inlineasm-error-t-toofewregs-mve.ll
@@ -0,0 +1,14 @@
+; RUN: not llc -mtriple=armv8.1-m-eabi -mattr=+mve %s -o /dev/null 2>&1 | FileCheck %s
+
+; CHECK: inline assembly requires more registers than available
+define arm_aapcs_vfpcc <4 x i32> @t-constraint-i32-vectors-too-few-regs(<4 x i32> %a, <4 x i32> %b) {
+entry:
+	%0 = tail call { <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+ <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32> }
+   asm "",
+ "=t,=t,=t,=t,=t,=t,=t,=t,=t,=t,t,t"(<4 x i32> %a, <4 x i32> %b)
+	%asmresult = extractvalue { <4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+<4 x i32>, <4 x i32>, <4 x i32>, <4 x i32>,
+<4 x i32>, <4 x i32> } %0, 0
+	ret <4 x i32> %asmresult
+}
Index: llvm/test/CodeGen/ARM/inlineasm.ll
===
--- llvm/test/CodeGen/ARM/inlineasm.ll
+++ llvm/test/CodeGen/ARM/inlineasm.ll
@@ -48,3 +48,27 @@
 	%0 = tail call <4 x float> asm "vadd.f32 $0, $1, $2", "=t,t,t"(<4 x float> %a, <4 x float> %b)
 	ret <4 x float> %0
 }
+
+define i32 @even-GPR-constraint() {
+entry:
+	; CHECK-LABEL: even-GPR-constraint
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[0, 2, 4, 6, 8]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1, #2\0Aadd $2, #3\0Aadd $3, #4\0A", "=^Te,=^Te,=^Te,=^Te,0,1,2,3"(i32 0, i32 0, i32 0, i32 0)
+	%asmresult = extractvalue { i32, i32, i32, i32 } %0, 0
+	ret i32 %asmresult
+}
+
+define i32 @odd-GPR-constraint() {
+entry:
+	; CHECK-LABEL: odd-GPR-constraint
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #1
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #2
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #3
+	; CHECK: add [[REG:r1*[1, 3, 5, 7, 9]]], [[REG]], #4
+	%0 = tail call { i32, i32, i32, i32 } asm "add $0, #1\0Aadd $1

[PATCH] D60709: [ARM] Support inline assembler constraints for MVE.

2019-06-26 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 3 inline comments as done.
simon_tatham added inline comments.



Comment at: cfe/trunk/lib/Basic/Targets/ARM.cpp:912
+  return true;
+}
   case 'U': // a memory reference...

craig.topper wrote:
> Is this supposed to fallthrough from 'T' to 'U'? If so can you add an 
> LLVM_FALLTHROUGH
No, it wasn't supposed to; sorry about that. rL364380 has fixed it in a way 
that looks right to me.



Comment at: llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp:14098
 }
+
+  case 2:

craig.topper wrote:
> Is this supposed to fallthrough from case 1 to case 2?
No, and rL364376 looks like the right fix to me.



Comment at: llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp:14113
+}
+
+  default:

craig.topper wrote:
> Is this supposed to fallthrough?
No, and rL364376 looks like the right fix to me.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60709



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


[PATCH] D63936: [ARM] Minor fixes in command line option parsing

2019-07-01 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

I can't shed as much light as you might hope, I'm afraid, but in D62998 
 my intention was not to make `-mcpu=anything` 
win over `-mfpu=anything`. It was to make an //explicit// request to enable a 
feature win over an //implicit// request to disable it. It so happened in my 
example that the explicit request was in the `-mcpu` option.

In the case you describe here, `-mcpu=cortex-a73 -mfpu=crypto-neon-fp-armv8`, 
the explicitness goes the other way round. Cortex-A73 might be listed in the 
CPU table without crypto, but that's not because it //can't// have crypto; it's 
because the cryptographic extension is an optional feature of the Cortex-A73, 
so it's just that it //need not// have crypto. So `-mcpu=cortex-a73` doesn't 
mean "definitely no crypto", it means "I haven't said whether I want crypto 
yet". And then the FPU specification asks for crypto (and in this case, crypto 
is even mentioned in the text of the FPU name). So here, it's the FPU 
specification that is (semi-)explicitly turning the feature //on//. So if a 
human user had written that command line, I would expect that then they surely 
//did// want crypto, and would be surprised not to get it.

But that's the kind of messy human reasoning you'd like to avoid implementing 
in software. I don't have a simple, consistent, general rule that gives the 
right answer to all these fiddly cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63936



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


[PATCH] D60691: [ARM] Replace fp-only-sp and d16 with fp64 and d32.

2019-05-28 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: llvm/test/MC/ARM/armv8.3a-js.s:16
 // REQ-V83: error: instruction requires: armv8.3a
-// REQ-FP: error: instruction requires: FPARMv8
+// REQ-FP: error: invalid instruction

ostannard wrote:
> Do you know why this diagnostic got worse?
I do now :-) It's because that instruction is invalid for two reasons: firstly, 
`vjcvt` requires FP-ARMv8 which the command line has turned off, and secondly, 
using d18 requires the new `d32` feature which the command line has also turned 
off. So `llc -debug` reports "Opcode result: multiple types of mismatch, so not 
reporting near-miss".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60691



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


[PATCH] D60691: [ARM] Replace fp-only-sp and d16 with fp64 and d32.

2019-05-28 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 4 inline comments as done.
simon_tatham added inline comments.



Comment at: llvm/lib/Target/ARM/ARMSubtarget.h:587
 
   bool hasVFP2() const { return HasVFPv2; }
   bool hasVFP3() const { return HasVFPv3; }

ostannard wrote:
> Are the old functions still used anywhere? If they are not used (much), I 
> think it would be better to just have one set of functions for the base FPU 
> version, and check hasFP64 and hasD32 where needed, to avoid the rick of 
> using the wrong version of these functions.
Indeed, it turned out the old functions weren't used anywhere at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60691



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


[PATCH] D67159: [clang] New __attribute__((__clang_builtin)).

2019-09-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 219691.
simon_tatham added a comment.

New version which renames the attribute to be MVE-specific, and locks it down 
as requested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/arm-mve-intrinsics/alias-attr.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test

Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/test/CodeGen/arm-mve-intrinsics/alias-attr.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mve-intrinsics/alias-attr.c
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop)))
+void nop(void); // expected-error {{__clang_arm_mve_alias attribute can only be used for Arm MVE builtins}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -5045,6 +5045,12 @@
   AL.getAttributeSpellingListIndex()));
 }
 
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(
+  AL.getRange(), S.Context, AL.getArgAsIdent(0)->Ident,
+  AL.getAttributeSpellingListIndex()));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7434,6 +7440,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias:
+handleArmMveAliasAttr(S, D, AL);
+break;
   }
 }
 
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -46,6 +46,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Specifiers.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetCXXABI.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/Visibility.h"
@@ -3077,6 +3078,11 @@
 
 FunctionDecl *FunctionDecl::getCanonicalDecl() { return getFirstDecl(); }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // This will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
 /// Returns a value indicating whether this function corresponds to a builtin
 /// function.
 ///
@@ -3091,10 +3097,24 @@
 /// functions as their wrapped builtins. This shouldn't be done in general, but
 /// it's useful in Sema to diagnose calls to wrappers based on their semantics.
 unsigned FunctionDecl::getBuiltinID(bool ConsiderWrapperFunctions) const {
-  if (!getIdentifier())
-return 0;
+  unsigned BuiltinID;
+
+  if (hasAttr()) {
+IdentifierInfo *II = getAttr()->getBuiltinName();
+BuiltinID = II->getBuiltinID();
+
+if (!ArmMveAliasValid(BuiltinID, getIdentifier()->getName())) {
+  getASTContext().getDiagnostics().Report(
+getLocation(), diag::err_attribute_arm_mve_alias);
+  return 0;
+}
+  } else {
+if (!getIdentifier())
+  return 0;
+
+BuiltinID = getIdentifier()->getBuiltinID();
+  }
 
-  unsigned BuiltinID = getIdentifier()->getBuiltinID();
   if (!BuiltinID)
 return 0;
 
@@ -3118,7 +3138,8 @@
 
   // If the function is marked "overloadable", it has a different mangled name
   // and is not the C library function.
-  if (!ConsiderWrapperFunctions && hasAttr())
+  if 

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

2019-09-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 219692.
simon_tatham added a comment.

Added a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67160

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/lax-vector-conversions.c


Index: clang/test/Driver/lax-vector-conversions.c
===
--- /dev/null
+++ clang/test/Driver/lax-vector-conversions.c
@@ -0,0 +1,8 @@
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main -### -c %s 2>&1 
\
+// RUN:   | FileCheck --check-prefix=CHECK-STRICT %s
+
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8a -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LAX %s
+
+// CHECK-STRICT: "-fno-lax-vector-conversions"
+// CHECK-LAX-NOT: "-fno-lax-vector-conversions"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1363,6 +1363,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4678,10 +4689,13 @@
   if (TC.SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_mfentry);
 
-  // -flax-vector-conversions is default.
-  if (!Args.hasFlag(options::OPT_flax_vector_conversions,
-options::OPT_fno_lax_vector_conversions))
+  if (const Arg *A = Args.getLastArg(options::OPT_flax_vector_conversions,
+options::OPT_fno_lax_vector_conversions)) {
+if (A->getOption().matches(options::OPT_fno_lax_vector_conversions))
+  CmdArgs.push_back("-fno-lax-vector-conversions");
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
 CmdArgs.push_back("-fno-lax-vector-conversions");
+  }
 
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))


Index: clang/test/Driver/lax-vector-conversions.c
===
--- /dev/null
+++ clang/test/Driver/lax-vector-conversions.c
@@ -0,0 +1,8 @@
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-STRICT %s
+
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8a -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LAX %s
+
+// CHECK-STRICT: "-fno-lax-vector-conversions"
+// CHECK-LAX-NOT: "-fno-lax-vector-conversions"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1363,6 +1363,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4678,10 +4689,13 @@
   if (TC.SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_mfentry);
 
-  // -flax-vector-conversions is default.
-  if (!Args.hasFlag(options::OPT_flax_vector_conversions,
-options::OPT_fno_lax_vector_conversions))
+  if (const Arg *A = Args.getLastArg(options::OPT_flax_vector_conversions,
+options::OPT_fno_lax_vector_conversions)) {
+if (A->getOption().matches(options::OPT_fno_lax_vector_conversions))
+  CmdArgs.push_back("-fno-lax-vector-conversions");
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
 CmdArgs.push_back("-fno-lax-vector-conversions");
+  }
 
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-02 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 10 inline comments as done.
simon_tatham added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3082
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // This will be filled in by Tablegen which isn't written yet
+  return false;

aaron.ballman wrote:
> Comment should have a `FIXME` prefix, but tbh, I'm a little uncomfortable 
> adopting the attribute without this being implemented. I assume the plan is 
> to tablegen a header file that gets included here to provide the lookup?
Yes: D67161, which I intend to commit as part of the same patch series once 
everything in it is approved, fills in this function with tablegen output.

I could roll both into the same monolithic patch, but I thought it would be 
better to break it up into manageable pieces as far as possible, especially 
when some of them (like this one) would need to be reviewed by people with 
significantly different expertise from the rest.



Comment at: clang/lib/AST/Decl.cpp:3107
+if (!ArmMveAliasValid(BuiltinID, getIdentifier()->getName())) {
+  getASTContext().getDiagnostics().Report(
+getLocation(), diag::err_attribute_arm_mve_alias);

aaron.ballman wrote:
> I'm not certain how comfortable I am with having this function produce a 
> diagnostic. That seems like unexpected behavior for a function attempting to 
> get a builtin ID. I think this should be the responsibility of the caller.
The //caller//? But there are many possible callers of this function. You 
surely didn't mean to suggest duplicating the diagnostic at all those call 
sites.

Perhaps it would make more sense to have all the calculation in this 
`getBuiltinID` method move into a function called once, early in the 
`FunctionDecl`'s lifetime, which figures out the builtin ID (if any) and 
stashes it in a member variable? Then //that// would issue the diagnostic, if 
any (and it would be called from a context where that was a sensible thing to 
do), and `getBuiltinID` itself would become a mere accessor function.



Comment at: clang/test/CodeGen/arm-mve-intrinsics/alias-attr.c:1
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+

aaron.ballman wrote:
> This seems like a Sema test, not a CodeGen test.
> 
> There are other Sema tests missing: the attribute only accepts one arg 
> instead of zero or two+, only accepts identifier args (test with a string 
> literal and an integer literal), only applies to functions, etc.
> 
> Should there be a diagnostic if the attribute is applied to a function with 
> internal linkage (or are there static builtins)? What about member functions 
> of a class?
> 
> Once the builtin hookup is complete, there should also be tests for the 
> attribute being accepted properly, and codegen tests demonstrating the proper 
> builtin is called.
Thanks for pointing out the rest of those missing test cases; I'll add them.

The //intended// use of this attribute is very similar to the example I show 
here (only with one of the upcoming MVE builtins in place of 
`__builtin_arm_nop`): declaring a function as `static __inline__` that 
corresponds to a builtin (either by name, or via this new attribute) has the 
effect of filling in the prototype of the function at compile time if it wasn't 
baked into `Builtins.def` up front. (Which I'll need to do for the MVE 
builtins, because some of them will have struct types as arguments that won't 
exist until the header file has defined them.)

I could add a diagnostic if the attribute is applied to a function with 
//external// linkage, and/or one for class member functions, if you think 
either one is important. (I don't expect to need either of those for my 
intended use case.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-02 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 222785.
simon_tatham marked an inline comment as done.
simon_tatham edited the summary of this revision.
simon_tatham added a comment.

Addressed many (but not quite all) review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop)))
+void nop(void); // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -4830,6 +4830,20 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!checkAttributeNumArgs(S, AL, 1))
+return;
+
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  D->addAttr(::new (S.Context)
+ ArmMveAliasAttr(S.Context, AL, AL.getArgAsIdent(0)->Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7174,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias:
+handleArmMveAliasAttr(S, D, AL);
+break;
   }
 }
 
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -46,6 +46,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Specifiers.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetCXXABI.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/Visibility.h"
@@ -3099,6 +3100,11 @@
 
 FunctionDecl *FunctionDecl::getCanonicalDecl() { return getFirstDecl(); }
 
+static bool ArmMveAliasVal

[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-02 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7442
+  case ParsedAttr::AT_ClangBuiltinOverride:
+handleClangBuiltinOverrideAttribute(S, D, AL);
+break;

aaron.ballman wrote:
> You should be able to call 
> `handleSimpleAttribute()` instead.
Oh, nearly forgot: apparently I can't, because that template expects the 
attribute to have a constructor that takes only an `ASTContext` and an 
`AttributeCommonInfo`. But the constructor for my attribute also takes an 
`IdentifierInfo` giving the builtin name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

2018-06-27 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
Herald added a subscriber: cfe-commits.

This option interposes a wrapper implementation of VirtualFileSystem
in front of the one in the CompilerInstance. The wrapper filesystem
differs from the standard one in that it tolerates backslashes as a
path separator even if the native path syntax doesn't, and also looks
up filenames case-insensitively even if the native file system is
case-sensitive.

This is intended to be useful to anyone compiling source code on Unix
whose authors had never prepared it to be compiled on anything but
Windows, so that it uses backslashes and inconsistent filename case in
its #include directives.

One particular example is if you're running clang-cl as a cross-
compiler, to build a Windows application on a Unix build host; another
is if you're developing a Unix port of a Windows code base in a
downstream clone of their repository. In either case, if you can't get
the upstream authors to take patches that make their #include
directives more portable, you might instead use this option to get
clang to tolerate the non-portable ones.


Repository:
  rC Clang

https://reviews.llvm.org/D48626

Files:
  include/clang/Basic/VirtualFileSystem.h
  include/clang/Driver/Options.td
  include/clang/Lex/HeaderSearchOptions.h
  lib/Basic/VirtualFileSystem.cpp
  lib/Frontend/CompilerInvocation.cpp

Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1846,6 +1846,9 @@
 
   for (const auto *A : Args.filtered(OPT_ivfsoverlay))
 Opts.AddVFSOverlayFile(A->getValue());
+
+  if (Args.hasArg(OPT_fwindows_filesystem))
+Opts.WindowsPathnameEmulation = true;
 }
 
 void CompilerInvocation::setLangDefaults(LangOptions &Opts, InputKind IK,
@@ -3212,28 +3215,36 @@
 createVFSFromCompilerInvocation(const CompilerInvocation &CI,
 DiagnosticsEngine &Diags,
 IntrusiveRefCntPtr BaseFS) {
-  if (CI.getHeaderSearchOpts().VFSOverlayFiles.empty())
-return BaseFS;
-
-  IntrusiveRefCntPtr Overlay(
-  new vfs::OverlayFileSystem(BaseFS));
-  // earlier vfs files are on the bottom
-  for (const auto &File : CI.getHeaderSearchOpts().VFSOverlayFiles) {
-llvm::ErrorOr> Buffer =
+  IntrusiveRefCntPtr FS = BaseFS;
+
+  if (!CI.getHeaderSearchOpts().VFSOverlayFiles.empty()) {
+IntrusiveRefCntPtr Overlay(
+  new vfs::OverlayFileSystem(FS));
+// earlier vfs files are on the bottom
+for (const auto &File : CI.getHeaderSearchOpts().VFSOverlayFiles) {
+  llvm::ErrorOr> Buffer =
 BaseFS->getBufferForFile(File);
-if (!Buffer) {
-  Diags.Report(diag::err_missing_vfs_overlay_file) << File;
-  continue;
-}
+  if (!Buffer) {
+Diags.Report(diag::err_missing_vfs_overlay_file) << File;
+continue;
+  }
 
-IntrusiveRefCntPtr FS = vfs::getVFSFromYAML(
+  IntrusiveRefCntPtr FS = vfs::getVFSFromYAML(
 std::move(Buffer.get()), /*DiagHandler*/ nullptr, File);
-if (FS)
-  Overlay->pushOverlay(FS);
-else
-  Diags.Report(diag::err_invalid_vfs_overlay) << File;
+  if (FS)
+Overlay->pushOverlay(FS);
+  else
+Diags.Report(diag::err_invalid_vfs_overlay) << File;
+}
+
+FS = std::move(Overlay);
   }
-  return Overlay;
+
+  if (CI.getHeaderSearchOpts().WindowsPathnameEmulation) {
+FS = createWindowsFileSystemWrapper(std::move(FS));
+  }
+
+  return FS;
 }
 
 } // namespace clang
Index: lib/Basic/VirtualFileSystem.cpp
===
--- lib/Basic/VirtualFileSystem.cpp
+++ lib/Basic/VirtualFileSystem.cpp
@@ -2024,3 +2024,170 @@
 
   return *this;
 }
+
+//===---===/
+// WindowsFileSystemWrapper implementation
+//===---===/
+
+class WindowsFileSystemWrapper : public vfs::FileSystem {
+  using String = SmallString<256>;
+
+  /// Path name style, used to identify path separators.
+  sys::path::Style PathStyle = sys::path::Style::windows;
+
+  /// The file system we are wrapping.
+  IntrusiveRefCntPtr BaseFS;
+
+  /// Data about the contents of a single directory.
+  struct DirectoryCaseMap {
+/// Map whose keys are the lowercase versions of filenames in that
+/// directory, and values are the version of the same name that
+/// actually exists.
+std::map Filenames;
+
+/// Flag indicating whether we've done a complete trawl of the
+/// directory yet, or whether we've only filled in a subset of
+/// filenames.
+bool Complete { false };
+
+/// If we couldn't even scan this directory due to a filesystem
+/// error, retain that error so we can return it again on the next
+/// attempt.
+std::error_code EC;
+  };
+
+  static String Lowercase(StringRef

[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

2018-06-27 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

As I mentioned on llvm-dev, this is an unfinished draft. I'm interested in 
review comments, but I already know things like 'needs more comments / tests / 
careful error handling' :-)

Some 'known unknowns':

- I'm caching the results of every directory scan, to save effort when more 
include files are needed from the same directory. That assumes that the 
lifetime of this filesystem object is short enough that we don't have to worry 
about new files appearing in directories we've already looked at, which seems 
like a reasonable assumption in an ordinary compile, but I don't know if the 
same filesystem abstraction might be used in completely different contexts 
elsewhere in the LLVM ecosystem and have a longer lifetime. Do I need to take a 
lot more care with my cache persistence?
- I was wondering if it might be worth having a second command-line option, to 
turn on only the case-insensitivity and not the backslash-separator tolerance 
(e.g. for use on source code developed for Mac rather than Windows).
- The option name is the first one that sprang to mind and I'm expecting 
someone will probably suggest a better one.


Repository:
  rC Clang

https://reviews.llvm.org/D48626



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


[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

2018-06-27 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

No, I haven't measured it. Partly because that was one of the (many) things I 
was going to leave until after I //didn't// get feedback on the first draft 
that discouraged me from the whole idea :-) and also because I've already 
thought of one thing I can do to speed it up that I haven't done yet.

(Namely, break the pathname down recursively from the RH end instead of 
iteratively from the LH, so that in the case where the whole pathname is 
already case-correct, the lookup can succeed immediately. Then any performance 
hit should be limited to //only// the cases that actually need fixing up.)

I can see that if you're on Linux specifically then a FUSE filesystem can solve 
the case insensitivity, albeit in a way that needs setup and teardown. But 
surely backslash path separators are still problematic in that situation? (Or 
does ciopfs have an option I didn't spot to fudge those too?)


Repository:
  rC Clang

https://reviews.llvm.org/D48626



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


[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

2018-06-28 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

@thakis : no, the backslash support is needed for include directives //in 
source files//, not just on command lines, because in my experience it's not 
unusual for Windows-only code bases to be full of things like `#include 
"Subdir\Header.h"`.

@mstorsjo : in this draft, I traverse the pathname from left to right, and at 
each level, if the normal case-sensitive lookup succeeds then I don't scan the 
whole directory looking for other options. As I mentioned above, though, I've 
since realised I should have done it the other way round, trying the case 
sensitive lookup on the //whole// pathname in one go first, and not even trying 
it one level at a time unless that fails.

Although, come to think of it, that's not good enough, because if you have 
multiple directories on your include //path// then you expect a lot of lookups 
to fail for reasons that have nothing to do with case. Say, if you compile with 
`-Ifoo -Ibar`, then every include of a file intended to be found in `bar` will 
force lots of pointless directory enumeration in `foo` when the initial lookup 
there doesn't find the file. Hmmm. That suggests to me that perhaps this ought 
not to be a //global// `-ffudge-my-paths` type option applying to all include 
directories, and instead perhaps it should be a new kind of `-I` option, so 
that only lookups relative to that particular include-path directory would get 
the unusual semantics. What do people think?


Repository:
  rC Clang

https://reviews.llvm.org/D48626



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


[PATCH] D48626: New option -fwindows-filesystem, affecting #include paths.

2018-06-28 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

> first check all directories in a fully case sensitive manner, just like 
> today. And if that fails (and we'd have a real failure that we'd otherwise 
> return to the caller), redo it all with case insensitivity.

I agree that the integration would be a bigger headache doing it that way. It 
would also depart from the expected semantics – a correctly cased header file 
in an include directory late on the path would override an incorrectly cased 
one earlier, which isn't how the real Windows compiler would handle the same 
situation.

> The cases where I would have needed this (the windows sdk), I'm not 
> specifying that path explicitly via -I directives, but implicitly via the 
> INCLUDE env variable

*blush* I //ought// to have thought of that, because I've noticed the same 
problem!

> but perhaps limiting this to the directories known to have problematic case 
> could be helpful performance wise.

Yes. OK, in that case I think my proposed replacement design is to have an 
option along the lines of `-fwindows-paths=`//prefix// (spelling still open to 
change), with the effect that only pathname lookups starting with that prefix 
will be subject to this transformation.


Repository:
  rC Clang

https://reviews.llvm.org/D48626



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


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3107
+if (!ArmMveAliasValid(BuiltinID, getIdentifier()->getName())) {
+  getASTContext().getDiagnostics().Report(
+getLocation(), diag::err_attribute_arm_mve_alias);

aaron.ballman wrote:
> simon_tatham wrote:
> > aaron.ballman wrote:
> > > I'm not certain how comfortable I am with having this function produce a 
> > > diagnostic. That seems like unexpected behavior for a function attempting 
> > > to get a builtin ID. I think this should be the responsibility of the 
> > > caller.
> > The //caller//? But there are many possible callers of this function. You 
> > surely didn't mean to suggest duplicating the diagnostic at all those call 
> > sites.
> > 
> > Perhaps it would make more sense to have all the calculation in this 
> > `getBuiltinID` method move into a function called once, early in the 
> > `FunctionDecl`'s lifetime, which figures out the builtin ID (if any) and 
> > stashes it in a member variable? Then //that// would issue the diagnostic, 
> > if any (and it would be called from a context where that was a sensible 
> > thing to do), and `getBuiltinID` itself would become a mere accessor 
> > function.
> > The caller? But there are many possible callers of this function. You 
> > surely didn't mean to suggest duplicating the diagnostic at all those call 
> > sites.
> 
> Yes, I did. :-) No caller is going to expect that calling a `const` function 
> that gets a builtin ID is going to issue diagnostics and so this runs the 
> risk of generating diagnostics in surprising situations, such as from AST 
> matchers.
> 
> > Perhaps it would make more sense to have all the calculation in this 
> > getBuiltinID method move into a function called once, early in the 
> > FunctionDecl's lifetime, which figures out the builtin ID (if any) and 
> > stashes it in a member variable? Then that would issue the diagnostic, if 
> > any (and it would be called from a context where that was a sensible thing 
> > to do), and getBuiltinID itself would become a mere accessor function.
> 
> That might make sense, but I don't have a good idea of what performance 
> concerns that might raise. If there are a lot of functions and we never need 
> to check if they have a builtin ID, that could be expensive for little gain.
OK – so actually what you meant to suggest was to put the diagnostic at just 
//some// of the call sites for `getBuiltinId`?

With the intended behavior being that the Sema test in this patch should still 
provoke all the expected diagnostics in an ordinary compilation context, but in 
other situations like AST matchers, it would be better for `getBuiltinId` to 
//silently// returns 0 if there's an illegal ArmMveAlias attribute?

(I'm just checking I've understood you correctly before I do the work...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D67161: [clang,ARM] Initial ACLE intrinsics for MVE.

2019-10-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 20 inline comments as done.
simon_tatham added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8529
   "argument should be a multiple of %0">;
+def err_argument_not_power_of_2 : Error<
+  "argument should be a power of 2">;

dmgreen wrote:
> Do we have any/should we have some tests for these errors?
By the time we finish implementing all the intrinsics, there will be tests for 
these errors. The intrinsics that need them aren't in this preliminary commit, 
though.



Comment at: clang/include/clang/Basic/arm_mve_defs.td:266
+// vidupq_wb_u16 -> vidupq_u16.
+def PNT_WB: PolymorphicNameType<0, "wb">;
+

dmgreen wrote:
> These are not used yet, right? They are not meant for the vldr gathers, those 
> don't have polymorphic names (if I'm reading this list of intrinsics right). 
> These are for vidup's as the comment says?
I've defined here the complete list of polymorphic name types that will be 
needed for //all// the MVE intrinsics. I haven't included an example of every 
single one in this preliminary set, though.

Yes, I think `PNT_WB` in particular is only used for the `vidup` family.



Comment at: clang/test/CodeGen/arm-mve-intrinsics/scalar-shifts.c:2
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O3 -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -DPOLYMORPHIC -O3 -S -emit-llvm -o - %s | FileCheck %s

dmgreen wrote:
> These tests all run -O3, the entire pass pipeline. I see quite a few tests in 
> the same folder do the same thing, but in this case we will be adding quite a 
> few tests. Random mid-end optimizations may well keep on altering them.
> 
> Is it possible to use -disable-O0-optnone and pipe them into opt -mem2reg? 
> What would that do to the codegen, would it be a lot more verbose than it is 
> now?
> 
> Also could/should they be using clang_cc1?
The immediate problem is that if you use any form of `clang | opt | FileCheck` 
command line, then `update_cc_test_checks.py` says 'skipping non-FileChecked 
line', because it doesn't support anything more complicated than a two-stage 
pipeline consisting of clang and FileCheck.

I've enhanced `update_cc_test_checks` to handle that case, in D68406, and 
respun these tests accordingly. But if that patch doesn't get approval then 
I'll have to rethink this again.

(For `vld24.c` I ended up running `opt -sroa -early-cse` to avoid the IR 
becoming noticeably more verbose. The rest worked fine with just `mem2reg`, 
though.)


Patching `update_cc_test_checks.py` to support more complex pipelines, it seems 
to work OK: most codegen changes are trivial ones, such as modifiers not 
appearing on IR operations (`call` instead of `tail call`, plain `shl` in place 
of `shl nuw`). Only `vld24` becomes significantly more complicated: for that 
one file I had to run `opt -mem2reg -sroa -early-cse` instead.



Comment at: clang/utils/TableGen/MveEmitter.cpp:82
+#if 0
+} // stop emacs from wanting to auto-indent everything to 2 spaces inside here
+#endif

dmgreen wrote:
> Is this needed still? It seems like something that should be handled in 
> clang-format/emacs directly.
Oh yes, now I look on Stack Overflow there is a way to make emacs stop 
indenting things inside namespaces. Thanks for the prod :-)



Comment at: clang/utils/TableGen/MveEmitter.cpp:1403
+" *\n"
+" * Permission is hereby granted, free of charge, to any person "
+"obtaining a copy\n"

dmgreen wrote:
> Clang format really made a mess of this, didn't it.
> 
> Is this is old license? Should it be updated to the new one. I imagine that 
> these generated headers might well have been missed in the switchover.
Seems likely! I've updated it to the same license that's at the top of this 
source file itself.



Comment at: clang/utils/TableGen/MveEmitter.cpp:132
+// the pointee type.
+Pointer,
+  };

dmgreen wrote:
> The gathers are really a Vector of Pointers, in a way. But in the intrinsics 
> (and IR), they are just treated as a vector of ints, so I presume a new type 
> is not needed? We may (but not yet) want to make use of the llvm masked 
> gathers. We would have to add codegen support for them first though (which I 
> don't think we have plans for in the near term).
Yes, I'm working so far on the assumption that we don't need to represent 
scatter/gather address vectors as a special vector-of-pointers type.

(If nothing else, it would be a bit strange for the 64-bit versions, where the 
vector element isn't even the same //size// as a pointer.)

If auto-generation of gather loads during vectorization turns out to need a 
sp

[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3107
+if (!ArmMveAliasValid(BuiltinID, getIdentifier()->getName())) {
+  getASTContext().getDiagnostics().Report(
+getLocation(), diag::err_attribute_arm_mve_alias);

aaron.ballman wrote:
> simon_tatham wrote:
> > aaron.ballman wrote:
> > > simon_tatham wrote:
> > > > aaron.ballman wrote:
> > > > > I'm not certain how comfortable I am with having this function 
> > > > > produce a diagnostic. That seems like unexpected behavior for a 
> > > > > function attempting to get a builtin ID. I think this should be the 
> > > > > responsibility of the caller.
> > > > The //caller//? But there are many possible callers of this function. 
> > > > You surely didn't mean to suggest duplicating the diagnostic at all 
> > > > those call sites.
> > > > 
> > > > Perhaps it would make more sense to have all the calculation in this 
> > > > `getBuiltinID` method move into a function called once, early in the 
> > > > `FunctionDecl`'s lifetime, which figures out the builtin ID (if any) 
> > > > and stashes it in a member variable? Then //that// would issue the 
> > > > diagnostic, if any (and it would be called from a context where that 
> > > > was a sensible thing to do), and `getBuiltinID` itself would become a 
> > > > mere accessor function.
> > > > The caller? But there are many possible callers of this function. You 
> > > > surely didn't mean to suggest duplicating the diagnostic at all those 
> > > > call sites.
> > > 
> > > Yes, I did. :-) No caller is going to expect that calling a `const` 
> > > function that gets a builtin ID is going to issue diagnostics and so this 
> > > runs the risk of generating diagnostics in surprising situations, such as 
> > > from AST matchers.
> > > 
> > > > Perhaps it would make more sense to have all the calculation in this 
> > > > getBuiltinID method move into a function called once, early in the 
> > > > FunctionDecl's lifetime, which figures out the builtin ID (if any) and 
> > > > stashes it in a member variable? Then that would issue the diagnostic, 
> > > > if any (and it would be called from a context where that was a sensible 
> > > > thing to do), and getBuiltinID itself would become a mere accessor 
> > > > function.
> > > 
> > > That might make sense, but I don't have a good idea of what performance 
> > > concerns that might raise. If there are a lot of functions and we never 
> > > need to check if they have a builtin ID, that could be expensive for 
> > > little gain.
> > OK – so actually what you meant to suggest was to put the diagnostic at 
> > just //some// of the call sites for `getBuiltinId`?
> > 
> > With the intended behavior being that the Sema test in this patch should 
> > still provoke all the expected diagnostics in an ordinary compilation 
> > context, but in other situations like AST matchers, it would be better for 
> > `getBuiltinId` to //silently// returns 0 if there's an illegal ArmMveAlias 
> > attribute?
> > 
> > (I'm just checking I've understood you correctly before I do the work...)
> > OK – so actually what you meant to suggest was to put the diagnostic at 
> > just some of the call sites for getBuiltinId?
> 
> Yes! Sorry, I can see how I was unclear before. :-)
> 
> > With the intended behavior being that the Sema test in this patch should 
> > still provoke all the expected diagnostics in an ordinary compilation 
> > context, but in other situations like AST matchers, it would be better for 
> > getBuiltinId to silently returns 0 if there's an illegal ArmMveAlias 
> > attribute?
> 
> Yes. `getBuiltinId()` already returns `0` in error cases without diagnosing, 
> such as the function being unnamed or not being a builtin. I want to retain 
> that property -- this function returns zero if the function is not a builtin. 
> It's up to the caller of the function to decide whether a zero return value 
> should be diagnosed or not.
> 
> To be honest, this diagnostic feels like it belongs in SemaDeclAttr.cpp; it 
> is placing a constraint on which declarations can have the attribute, so that 
> should be checked *before* applying the attribute to the declaration. This 
> also keeps the AST cleaner by not having an attribute on a function which 
> should not be attributed.
> `getBuiltinId()` already returns `0` in error cases without diagnosing

Ah, I hadn't spotted that! That by itself makes it all make a lot more sense to 
me.

> this diagnostic feels like it belongs in SemaDeclAttr.cpp

OK, I'll look at moving it there. Thanks for the pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 223550.
simon_tatham added a comment.

Moved the diagnostic into `SemaDeclAttr.cpp` as suggested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+void nop(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
@@ -4830,6 +4831,33 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // FIXME: this will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!checkAttributeNumArgs(S, AL, 1))
+return;
+
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  IdentifierInfo *Ident = AL.getArgAsIdent(0)->Ident;
+  unsigned BuiltinID = Ident->getBuiltinID();
+
+  if (!ArmMveAliasValid(BuiltinID,
+cast(D)->getIdentifier()->getName())) {
+S.Diag(AL.getLoc(), diag::err_attribute_arm_mve_alias);
+return;
+  }
+
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(S.Context, AL, Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7188,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+ 

[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-07 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3107
+if (!ArmMveAliasValid(BuiltinID, getIdentifier()->getName())) {
+  getASTContext().getDiagnostics().Report(
+getLocation(), diag::err_attribute_arm_mve_alias);

simon_tatham wrote:
> aaron.ballman wrote:
> > simon_tatham wrote:
> > > aaron.ballman wrote:
> > > > simon_tatham wrote:
> > > > > aaron.ballman wrote:
> > > > > > I'm not certain how comfortable I am with having this function 
> > > > > > produce a diagnostic. That seems like unexpected behavior for a 
> > > > > > function attempting to get a builtin ID. I think this should be the 
> > > > > > responsibility of the caller.
> > > > > The //caller//? But there are many possible callers of this function. 
> > > > > You surely didn't mean to suggest duplicating the diagnostic at all 
> > > > > those call sites.
> > > > > 
> > > > > Perhaps it would make more sense to have all the calculation in this 
> > > > > `getBuiltinID` method move into a function called once, early in the 
> > > > > `FunctionDecl`'s lifetime, which figures out the builtin ID (if any) 
> > > > > and stashes it in a member variable? Then //that// would issue the 
> > > > > diagnostic, if any (and it would be called from a context where that 
> > > > > was a sensible thing to do), and `getBuiltinID` itself would become a 
> > > > > mere accessor function.
> > > > > The caller? But there are many possible callers of this function. You 
> > > > > surely didn't mean to suggest duplicating the diagnostic at all those 
> > > > > call sites.
> > > > 
> > > > Yes, I did. :-) No caller is going to expect that calling a `const` 
> > > > function that gets a builtin ID is going to issue diagnostics and so 
> > > > this runs the risk of generating diagnostics in surprising situations, 
> > > > such as from AST matchers.
> > > > 
> > > > > Perhaps it would make more sense to have all the calculation in this 
> > > > > getBuiltinID method move into a function called once, early in the 
> > > > > FunctionDecl's lifetime, which figures out the builtin ID (if any) 
> > > > > and stashes it in a member variable? Then that would issue the 
> > > > > diagnostic, if any (and it would be called from a context where that 
> > > > > was a sensible thing to do), and getBuiltinID itself would become a 
> > > > > mere accessor function.
> > > > 
> > > > That might make sense, but I don't have a good idea of what performance 
> > > > concerns that might raise. If there are a lot of functions and we never 
> > > > need to check if they have a builtin ID, that could be expensive for 
> > > > little gain.
> > > OK – so actually what you meant to suggest was to put the diagnostic at 
> > > just //some// of the call sites for `getBuiltinId`?
> > > 
> > > With the intended behavior being that the Sema test in this patch should 
> > > still provoke all the expected diagnostics in an ordinary compilation 
> > > context, but in other situations like AST matchers, it would be better 
> > > for `getBuiltinId` to //silently// returns 0 if there's an illegal 
> > > ArmMveAlias attribute?
> > > 
> > > (I'm just checking I've understood you correctly before I do the work...)
> > > OK – so actually what you meant to suggest was to put the diagnostic at 
> > > just some of the call sites for getBuiltinId?
> > 
> > Yes! Sorry, I can see how I was unclear before. :-)
> > 
> > > With the intended behavior being that the Sema test in this patch should 
> > > still provoke all the expected diagnostics in an ordinary compilation 
> > > context, but in other situations like AST matchers, it would be better 
> > > for getBuiltinId to silently returns 0 if there's an illegal ArmMveAlias 
> > > attribute?
> > 
> > Yes. `getBuiltinId()` already returns `0` in error cases without 
> > diagnosing, such as the function being unnamed or not being a builtin. I 
> > want to retain that property -- this function returns zero if the function 
> > is not a builtin. It's up to the caller of the function to decide whether a 
> > zero return value should be diagnosed or not.
> > 
> > To be honest, this diagnostic feels like it belongs in SemaDeclAttr.cpp; it 
> > is placing a constraint on which declarations can have the attribute, so 
> > that should be checked *before* applying the attribute to the declaration. 
> > This also keeps the AST cleaner by not having an attribute on a function 
> > which should not be attributed.
> > `getBuiltinId()` already returns `0` in error cases without diagnosing
> 
> Ah, I hadn't spotted that! That by itself makes it all make a lot more sense 
> to me.
> 
> > this diagnostic feels like it belongs in SemaDeclAttr.cpp
> 
> OK, I'll look at moving it there. Thanks for the pointer.
I made this change, and discovered that as a side effect, this diagnostic is 
now reported on the same one of the two source lines as all the others in my 
test f

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

2019-10-09 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 224031.
simon_tatham added a comment.

Rebased to current master.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67160

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/lax-vector-conversions.c


Index: clang/test/Driver/lax-vector-conversions.c
===
--- /dev/null
+++ clang/test/Driver/lax-vector-conversions.c
@@ -0,0 +1,8 @@
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main -### -c %s 2>&1 
\
+// RUN:   | FileCheck --check-prefix=CHECK-STRICT %s
+
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8a -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LAX %s
+
+// CHECK-STRICT: "-flax-vector-conversions=none"
+// CHECK-LAX-NOT: "-flax-vector-conversions=none"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1377,6 +1377,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4678,7 +4689,11 @@
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
 
-  Args.AddLastArg(CmdArgs, options::OPT_flax_vector_conversions_EQ);
+  if (Args.getLastArg(options::OPT_flax_vector_conversions_EQ)) {
+Args.AddLastArg(CmdArgs, options::OPT_flax_vector_conversions_EQ);
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
+CmdArgs.push_back("-flax-vector-conversions=none");
+  }
   Args.AddLastArg(CmdArgs, options::OPT_fobjc_sender_dependent_dispatch);
   Args.AddLastArg(CmdArgs, options::OPT_fdiagnostics_print_source_range_info);
   Args.AddLastArg(CmdArgs, options::OPT_fdiagnostics_parseable_fixits);


Index: clang/test/Driver/lax-vector-conversions.c
===
--- /dev/null
+++ clang/test/Driver/lax-vector-conversions.c
@@ -0,0 +1,8 @@
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-STRICT %s
+
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8a -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LAX %s
+
+// CHECK-STRICT: "-flax-vector-conversions=none"
+// CHECK-LAX-NOT: "-flax-vector-conversions=none"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1377,6 +1377,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4678,7 +4689,11 @@
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
 
-  Args.AddLastArg(CmdArgs, options::OPT_flax_vector_conversions_EQ);
+  if (Args.getLastArg(options::OPT_flax_vector_conversions_EQ)) {
+Args.AddLastArg(CmdArgs, options::OPT_flax_vector_conversions_EQ);
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
+CmdArgs.push_back("-flax-vector-conversions=none");
+  }
   Args.AddLastArg(CmdArgs, options::OPT_fobjc_sender_dependent_dispatch);
   Args.AddLastArg(CmdArgs, options::OPT_fdiagnostics_print_source_range_info);
   Args.AddLastArg(CmdArgs, options::OPT_fdiagnostics_parseable_fixits);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-09 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 224030.
simon_tatham added a comment.

Rebased to current master.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+void nop(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
@@ -4830,6 +4831,33 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // FIXME: this will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!checkAttributeNumArgs(S, AL, 1))
+return;
+
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  IdentifierInfo *Ident = AL.getArgAsIdent(0)->Ident;
+  unsigned BuiltinID = Ident->getBuiltinID();
+
+  if (!ArmMveAliasValid(BuiltinID,
+cast(D)->getIdentifier()->getName())) {
+S.Diag(AL.getLoc(), diag::err_attribute_arm_mve_alias);
+return;
+  }
+
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(S.Context, AL, Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7188,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

2019-10-09 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Yes, the commit message in rL371817  
mentions that the long-term aim is to change the default to `none` for 
everyone. If that change happens before I manage to land this patch, then this 
patch certainly will become unnecessary.

But D68683  doesn't make that change: it only 
prepares `arm_neon.h` not to fall over in future when the change does happen. 
And MVE needs strict vector type checking more urgently than anyone else 
(because for us, it's not just a nice-to-have error-checking improvement, but 
critical to the polymorphic ACLE intrinsics working properly in the first 
place).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67160



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


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-10 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 224288.
simon_tatham marked 3 inline comments as done.
simon_tatham added a comment.

Removed spuriously inserted blank line and redundant `checkAttributeNumArgs`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+void nop(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
@@ -4830,6 +4831,30 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // FIXME: this will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  IdentifierInfo *Ident = AL.getArgAsIdent(0)->Ident;
+  unsigned BuiltinID = Ident->getBuiltinID();
+
+  if (!ArmMveAliasValid(BuiltinID,
+cast(D)->getIdentifier()->getName())) {
+S.Diag(AL.getLoc(), diag::err_attribute_arm_mve_alias);
+return;
+  }
+
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(S.Context, AL, Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7185,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias:
+h

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

2019-10-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Hmmm. I take your point, and so I backed out my local version of this patch in 
order to try to solve the problem a different way in overload resolution.

But in fact overloading on different vector types already seems to work fine: 
my in-progress patch series still passes all the clang tests even without this 
change to the defaults. So unless there's been a fix to overload resolution 
since I started developing all of this (I looked, and didn't find one), I can't 
quite work out why I needed this patch in the first place now. It may be that 
it's completely unnecessary, and that I managed to fool myself early in 
development by misinterpreting some other kind of mistake I'd made.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67160



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


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Thanks for the review!

(I expect to leave this uncommitted until I have enough other patches approved 
to make it actually useful, and then commit them all together.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added a reviewer: dmgreen.
Herald added subscribers: cfe-commits, kristof.beyls.
Herald added a project: clang.

Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
FP registers, it should turn off the MVE vector instructions as well
as NEON and scalar FP. But it wasn't doing so.

So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
would cause the underlying LLVM to //not// support MVE (because it
knows the real target feature relationships and turned off MVE when
the `fpregs` feature was removed), but the clang layer still thought
it //was// supported, and would misleadingly define the feature macro
`__ARM_FEATURE_MVE`.

The ARM driver code already has a long list of feature names to turn
off when `-mfloat-abi=soft` is selected. The fix is to add the missing
entries `mve` and `mve.fp` to that list.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69025

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-mfpu.c


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s 
-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s -march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Yes: this change is in the driver, and causes those features to be disabled on 
the command line to cc1, which responds by not defining `__ARM_FEATURE_MVE`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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


[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

So, as for adding a test ... the test I //have// added here ensures that this 
combination of driver options leads to `-target-feature -mve` and `-mve.fp` on 
the cc1 command line, and the existing test 
`Preprocessor/arm-target-features.c` checks that that in turn leads to 
`__ARM_FEATURE_MVE` not being defined.

A single end-to-end test that proves that //these// driver args lead to 
//that// preprocessor definition (or not) doesn't really have a place to live.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025



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


[PATCH] D69025: [Driver,ARM] Make -mfloat-abi=soft turn off MVE.

2019-10-16 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfdccf28697e5: [Driver,ARM] Make -mfloat-abi=soft turn off 
MVE. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69025

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-mfpu.c


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s 
-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }


Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -397,3 +397,9 @@
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+fp-armv8"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+neon"
 // CHECK-ARM7-ANDROID-FP-D16-NOT: "-target-feature" "+crypto"
+
+// RUN: %clang -target arm-none-none-eabi %s -march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft -### -c 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-SOFTFLOATABI-INHIBITS-MVE %s
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-NOT: "-target-feature" "+mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve"
+// CHECK-SOFTFLOATABI-INHIBITS-MVE-DAG: "-target-feature" "-mve.fp"
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -465,6 +465,7 @@
 "vfp4", "vfp4sp", "vfp4d16", "vfp4d16sp",
 "fp-armv8", "fp-armv8sp", "fp-armv8d16", "fp-armv8d16sp",
 "fullfp16", "neon", "crypto", "dotprod", "fp16fml",
+"mve", "mve.fp",
 "fp64", "d32", "fpregs"})
   Features.push_back(Args.MakeArgString("-" + Feature));
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-24 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 226238.
simon_tatham added a comment.

(Rebased to current master; no change)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+void nop(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
@@ -4830,6 +4831,30 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // FIXME: this will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  IdentifierInfo *Ident = AL.getArgAsIdent(0)->Ident;
+  unsigned BuiltinID = Ident->getBuiltinID();
+
+  if (!ArmMveAliasValid(BuiltinID,
+cast(D)->getIdentifier()->getName())) {
+S.Diag(AL.getLoc(), diag::err_attribute_arm_mve_alias);
+return;
+  }
+
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(S.Context, AL, Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7185,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias:
+handleArmMveAliasAttr(S, D, AL);
+break;
   }
 }
 
Index: clang/lib/AST/Decl.cpp
==

[PATCH] D67159: [clang] New __attribute__((__clang_arm_mve_alias)).

2019-10-24 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7c11da0cfd33: [clang] New 
__attribute__((__clang_arm_mve_alias)). (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/arm-mve-alias-attribute.c

Index: clang/test/Sema/arm-mve-alias-attribute.c
===
--- /dev/null
+++ clang/test/Sema/arm-mve-alias-attribute.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple armv8.1m.main-arm-none-eabi -verify -fsyntax-only %s
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute can only be applied to an ARM MVE builtin}}
+void nop(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias)) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void noparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias())) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void emptyparens(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias("string literal"))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void stringliteral(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(1))) // expected-error {{'__clang_arm_mve_alias' attribute requires parameter 1 to be an identifier}}
+void integer(void);
+
+static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_arm_nop, 2))) // expected-error {{'__clang_arm_mve_alias' attribute takes one argument}}
+void twoargs(void);
+
+static __attribute__((__clang_arm_mve_alias(__builtin_arm_nop))) // expected-error {{'__clang_arm_mve_alias' attribute only applies to functions}}
+int variable;
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -17,6 +17,7 @@
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
+// CHECK-NEXT: ArmMveAlias (SubjectMatchRule_function)
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Sema/DeclSpec.h"
@@ -4830,6 +4831,30 @@
  XRayLogArgsAttr(S.Context, AL, ArgCount.getSourceIndex()));
 }
 
+static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
+  // FIXME: this will be filled in by Tablegen which isn't written yet
+  return false;
+}
+
+static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!AL.isArgIdent(0)) {
+S.Diag(AL.getLoc(), diag::err_attribute_argument_n_type)
+<< AL << 1 << AANT_ArgumentIdentifier;
+return;
+  }
+
+  IdentifierInfo *Ident = AL.getArgAsIdent(0)->Ident;
+  unsigned BuiltinID = Ident->getBuiltinID();
+
+  if (!ArmMveAliasValid(BuiltinID,
+cast(D)->getIdentifier()->getName())) {
+S.Diag(AL.getLoc(), diag::err_attribute_arm_mve_alias);
+return;
+  }
+
+  D->addAttr(::new (S.Context) ArmMveAliasAttr(S.Context, AL, Ident));
+}
+
 //===--===//
 // Checker-specific attribute handlers.
 //===--===//
@@ -7160,6 +7185,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ArmMveAlias:
+handleArmMveAliasAttr

[PATCH] D67161: [clang,ARM] Initial ACLE intrinsics for MVE.

2019-10-25 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/utils/TableGen/CMakeLists.txt:17
   NeonEmitter.cpp
+  MveEmitter.cpp
   TableGen.cpp

thakis wrote:
> nit: These files are listed alphabetically.
Sorry about that. Fixed in rG24ef631f4333120abd6b66c1e8466a582b60779f


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67161



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


[PATCH] D69426: [clang] Switch arm-mve-intrinsics tests to use %clang_cc1.

2019-10-25 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added a reviewer: dmgreen.
Herald added subscribers: cfe-commits, kristof.beyls.
Herald added a project: clang.
simon_tatham edited the summary of this revision.

It isn't really necessary for them to run the clang driver, and it's
more efficient not to (and also more stable against driver changes).
Now they invoke cc1 directly, more like the analogous NEON tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69426

Files:
  clang/test/CodeGen/arm-mve-intrinsics/scalar-shifts.c
  clang/test/CodeGen/arm-mve-intrinsics/vadc.c
  clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
  clang/test/CodeGen/arm-mve-intrinsics/vld24.c
  clang/test/CodeGen/arm-mve-intrinsics/vldr.c
  clang/test/CodeGen/arm-mve-intrinsics/vminvq.c


Index: clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -DPOLYMORPHIC -O0 -Xclang -disable-O0-optnone 
-fno-discard-value-names -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -DPOLYMORPHIC -S -emit-llvm -o 
- %s | opt -S -mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vldr.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vldr.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vldr.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vld24.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vld24.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vld24.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg -sroa -early-cse | FileCheck %s
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -DPOLYMORPHIC -O0 -Xclang -disable-O0-optnone 
-fno-discard-value-names -S -emit-llvm -o - %s | opt -S -mem2reg -sroa 
-early-cse | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg -sroa -early-cse | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -DPOLYMORPHIC -S -emit-llvm -o 
- %s | opt -S -mem2reg -sroa -early-cse | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -di

[PATCH] D69426: [clang] Switch arm-mve-intrinsics tests to use %clang_cc1.

2019-10-25 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

There's no need, as far as I can see. `-fno-discard-value-names` is a driver 
option only. On the cc1 command line the option is `-discard-value-names`, and 
it has no negative form: you turn it off by not specifying it in the first 
place, which indeed these command lines don't.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69426



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


[PATCH] D69426: [clang] Switch arm-mve-intrinsics tests to use %clang_cc1.

2019-10-25 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG11ce19d2119e: [clang] Switch arm-mve-intrinsics tests to use 
%clang_cc1. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69426

Files:
  clang/test/CodeGen/arm-mve-intrinsics/scalar-shifts.c
  clang/test/CodeGen/arm-mve-intrinsics/vadc.c
  clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
  clang/test/CodeGen/arm-mve-intrinsics/vld24.c
  clang/test/CodeGen/arm-mve-intrinsics/vldr.c
  clang/test/CodeGen/arm-mve-intrinsics/vminvq.c


Index: clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -DPOLYMORPHIC -O0 -Xclang -disable-O0-optnone 
-fno-discard-value-names -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -DPOLYMORPHIC -S -emit-llvm -o 
- %s | opt -S -mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vldr.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vldr.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vldr.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vld24.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vld24.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vld24.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg -sroa -early-cse | FileCheck %s
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -DPOLYMORPHIC -O0 -Xclang -disable-O0-optnone 
-fno-discard-value-names -S -emit-llvm -o - %s | opt -S -mem2reg -sroa 
-early-cse | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg -sroa -early-cse | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -DPOLYMORPHIC -S -emit-llvm -o 
- %s | opt -S -mem2reg -sroa -early-cse | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv8.1m.main-arm-none-eabi -target-feature 
+mve.fp -mfloat-abi hard -O0 -disable-O0-optnone -S -emit-llvm -o - %s | opt -S 
-mem2reg | FileCheck %s
 
 #include 
 
Index: clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
===
--- clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
+++ clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
@@ -1,6 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m.main+mve.fp 
-mfloat-abi=hard -O0 -Xclang -disable-O0-optnone -fno-discard-value-names -S 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang --target=arm-arm-none-eabi -march=armv8.1m

cfe-commits@lists.llvm.org

2020-05-28 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:10366
+auto Alignment = CGM.getNaturalPointeeTypeAlignment(
+E->getArg(0)->IgnoreParenCasts()->getType());
 Ops[0] = Builder.CreateBitCast(Ops[0], llvm::PointerType::getUnqual(VTy));

What effect is this change of strategy having on the alignment computation, for 
the already-supported instances of this builtin?

It //looks// to me as if `__builtin_neon_vld1_v` with (say) a `uint8_t *` 
pointer argument will now compute `Alignment=1` (the natural alignment of the 
pointee type), whereas it would previously have computed `Alignment=8` (the 
size of the whole vector being loaded or stored).

Is that intentional? Or accidental? Or have I completely misunderstood what's 
going on?

(Whichever of the three, some discussion in the commit message would be a good 
idea, explaining why this change does or does not make a difference, as 
appropriate.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80716



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


[PATCH] D82659: Fix missing build dependency on omp_gen.

2020-07-01 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

In D82659#2125618 , @clementval wrote:

> LGTM. So later the DEPENDS omp_gen that are in clang subdirectories could be 
> removed right?


That seems likely. I'm thinking what I should probably do is to polish up my 
checking script and try to get it into `llvm/utils` somewhere, and then it 
would be possible to make that kind of change and be //confident// that it 
wasn't removing a necessary dependency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82659



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


[PATCH] D82659: Fix missing build dependency on omp_gen.

2020-07-01 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

[facepalm] Thank you. I carefully //wrote// a revised description, but forgot 
to upload it to this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82659



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


[PATCH] D82659: Fix missing build dependency on omp_gen.

2020-07-02 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9e6f19fd8390: Fix missing build dependency on omp_gen. 
(authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82659

Files:
  clang/CMakeLists.txt


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -517,7 +517,10 @@
 
 # All targets below may depend on all tablegen'd files.
 get_property(CLANG_TABLEGEN_TARGETS GLOBAL PROPERTY CLANG_TABLEGEN_TARGETS)
-add_custom_target(clang-tablegen-targets DEPENDS ${CLANG_TABLEGEN_TARGETS})
+add_custom_target(clang-tablegen-targets
+  DEPENDS
+  omp_gen
+  ${CLANG_TABLEGEN_TARGETS})
 set_target_properties(clang-tablegen-targets PROPERTIES FOLDER "Misc")
 list(APPEND LLVM_COMMON_DEPENDS clang-tablegen-targets)
 


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -517,7 +517,10 @@
 
 # All targets below may depend on all tablegen'd files.
 get_property(CLANG_TABLEGEN_TARGETS GLOBAL PROPERTY CLANG_TABLEGEN_TARGETS)
-add_custom_target(clang-tablegen-targets DEPENDS ${CLANG_TABLEGEN_TARGETS})
+add_custom_target(clang-tablegen-targets
+  DEPENDS
+  omp_gen
+  ${CLANG_TABLEGEN_TARGETS})
 set_target_properties(clang-tablegen-targets PROPERTIES FOLDER "Misc")
 list(APPEND LLVM_COMMON_DEPENDS clang-tablegen-targets)
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D82659: Fix missing build dependency on omp_gen.

2020-07-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

@jdoerfert , @clementval : over in D83032  is 
a polished-up version of the script I used to check where the missing deps 
needed to go. Might be useful for the next problem of this kind. But I'm not 
sure who to get to review it; perhaps one of you might look at it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82659



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


[PATCH] D82659: Fix missing build dependency on omp_gen.

2020-07-01 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 274739.
simon_tatham added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Here's a completely different patch, which adds all the missing dependencies on 
`OMP.h.inc` in the `clang` subdirectory in one go.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82659

Files:
  clang/CMakeLists.txt


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -517,7 +517,10 @@
 
 # All targets below may depend on all tablegen'd files.
 get_property(CLANG_TABLEGEN_TARGETS GLOBAL PROPERTY CLANG_TABLEGEN_TARGETS)
-add_custom_target(clang-tablegen-targets DEPENDS ${CLANG_TABLEGEN_TARGETS})
+add_custom_target(clang-tablegen-targets
+  DEPENDS
+  omp_gen
+  ${CLANG_TABLEGEN_TARGETS})
 set_target_properties(clang-tablegen-targets PROPERTIES FOLDER "Misc")
 list(APPEND LLVM_COMMON_DEPENDS clang-tablegen-targets)
 


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -517,7 +517,10 @@
 
 # All targets below may depend on all tablegen'd files.
 get_property(CLANG_TABLEGEN_TARGETS GLOBAL PROPERTY CLANG_TABLEGEN_TARGETS)
-add_custom_target(clang-tablegen-targets DEPENDS ${CLANG_TABLEGEN_TARGETS})
+add_custom_target(clang-tablegen-targets
+  DEPENDS
+  omp_gen
+  ${CLANG_TABLEGEN_TARGETS})
 set_target_properties(clang-tablegen-targets PROPERTIES FOLDER "Misc")
 list(APPEND LLVM_COMMON_DEPENDS clang-tablegen-targets)
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-07-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, 
RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli.
Herald added subscribers: cfe-commits, dexonsmith, kristof.beyls.
Herald added a project: clang.
simon_tatham requested review of this revision.

Vectors of bfloat are a storage format only; you're supposed to
explicitly convert them to a wider type to do arithmetic on them.
But currently, if you write something like

  bfloat16x4_t test(bfloat16x4_t a, bfloat16x4_t b) { return a + b; }

then the clang frontend accepts it without error, and (ARM or AArch64)
isel fails to generate code for it.

Added a rule in Sema that forbids the attempt from even being made,
and tests that check it. In particular, we also outlaw arithmetic
between vectors of bfloat and any other vector type.

Patch by Luke Cheeseman.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85009

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/arm-bfloat.cpp


Index: clang/test/Sema/arm-bfloat.cpp
===
--- clang/test/Sema/arm-bfloat.cpp
+++ clang/test/Sema/arm-bfloat.cpp
@@ -27,3 +27,21 @@
   fp16 = bf16; // expected-error {{assigning to '__fp16' from incompatible 
type '__bf16'}}
   bf16 + (b ? fp16 : bf16); // expected-error {{incompatible operand types 
('__fp16' and '__bf16')}}
 }
+
+#include 
+
+void test_vector(bfloat16x4_t a, bfloat16x4_t b, float16x4_t c) {
+  a + b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a - b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a * b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a / b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+
+  a + c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a - c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a * c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a / c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  c + b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c - b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c * b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c / b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -9790,6 +9790,10 @@
   const VectorType *RHSVecType = RHSType->getAs();
   assert(LHSVecType || RHSVecType);
 
+  if ((LHSVecType && LHSVecType->getElementType()->isBFloat16Type()) ||
+  (RHSVecType && RHSVecType->getElementType()->isBFloat16Type()))
+return InvalidOperands(Loc, LHS, RHS);
+
   // AltiVec-style "vector bool op vector bool" combinations are allowed
   // for some operators but not others.
   if (!AllowBothBool &&


Index: clang/test/Sema/arm-bfloat.cpp
===
--- clang/test/Sema/arm-bfloat.cpp
+++ clang/test/Sema/arm-bfloat.cpp
@@ -27,3 +27,21 @@
   fp16 = bf16; // expected-error {{assigning to '__fp16' from incompatible type '__bf16'}}
   bf16 + (b ? fp16 : bf16); // expected-error {{incompatible operand types ('__fp16' and '__bf16')}}
 }
+
+#include 
+
+void test_vector(bfloat16x4_t a, bfloat16x4_t b, float16x4_t c) {
+  a + b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a - b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a * b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a / b; // expected-error {{inva

[PATCH] D85010: [clang][ARM] Add name-mangling test for direct __fp16 arguments.

2020-07-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: LukeGeeson, stuij, chill, miyuki, labrinea.
Herald added subscribers: cfe-commits, danielkiss, kristof.beyls.
Herald added a project: clang.
simon_tatham requested review of this revision.

`clang/test/CodeGenCXX/fp16-mangle.cpp` tests pointers to __fp16, but
if you give the `-fallow-half-arguments-and-returns` option, then
clang can also leave an __fp16 unmodified as a function argument or
return type. This regression test checks the name-mangling of that.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85010

Files:
  clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp


Index: clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-arm-none-eabi 
-fallow-half-arguments-and-returns %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple aarch64-arm-none-eabi 
-fallow-half-arguments-and-returns %s | FileCheck %s
+
+// Test name-mangling of __fp16 passed directly as a function argument
+// (when that is permitted).
+
+// CHECK: define {{.*}}void @_Z13fp16_argumentDh(half %{{.*}})
+void fp16_argument(__fp16 arg) {}
+
+// Test name-mangling of __fp16 as a return type. The return type of
+// fp16_return itself isn't mentioned in the mangled name, so to test
+// this, we have to pass it a function pointer and make __fp16 the
+// return type of that.
+
+// CHECK: define {{.*}}void @_Z11fp16_returnPFDhvE(half ()* %{{.*}})
+void fp16_return(__fp16 (*func)(void)) {}


Index: clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-arm-none-eabi -fallow-half-arguments-and-returns %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple aarch64-arm-none-eabi -fallow-half-arguments-and-returns %s | FileCheck %s
+
+// Test name-mangling of __fp16 passed directly as a function argument
+// (when that is permitted).
+
+// CHECK: define {{.*}}void @_Z13fp16_argumentDh(half %{{.*}})
+void fp16_argument(__fp16 arg) {}
+
+// Test name-mangling of __fp16 as a return type. The return type of
+// fp16_return itself isn't mentioned in the mangled name, so to test
+// this, we have to pass it a function pointer and make __fp16 the
+// return type of that.
+
+// CHECK: define {{.*}}void @_Z11fp16_returnPFDhvE(half ()* %{{.*}})
+void fp16_return(__fp16 (*func)(void)) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-07-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

In D85009#2187549 , @jfb wrote:

> Is that true of all vector bfloat implementations? It seems like arithmetic 
> on these types is something implementations would likely support.

As I understand it, Arm currently has the only implementation in clang so far. 
But if other targets disagree, we can make this conditional on 
`getVectorKind()`, so that `VectorType::NeonVector` gets this restriction and 
other vector types get whatever they need.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009

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


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-07-31 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

In D85009#2187621 , @jfb wrote:

> You mean: only aarch64 backend supports lowering bfloat16 vectors at the 
> moment?

Yes, sorry – I should have said that Arm has the only implementation //in an 
LLVM target//. I meant the only one "in clang" in the sense of "compiled into 
the overall clang binary", which was unclear of me.

I agree that from a front end / language specification perspective this is 
tricky. That's why I mentioned the vector kind. The //scalar// bfloat type may 
have to have the same source-language semantics across all targets, but when it 
comes to vectors, each target will define a different set of vector types. The 
Arm header files will be defining something along the lines of

  typedef __attribute__((neon_vector_type(8))) bfloat16_t bfloat16x8_t;

and the next target that wants to use a vector of bfloat will presumably do 
something similar with a different `foo_vector_type` attribute (and quite 
likely a different set of vector lengths too).

Vector architectures are more or less //certain// to vary in the range of 
operations they permit, so it seems reasonable to me that clang will end up 
wanting to treat a `neon_vector_type` vector of bfloats differently from 
whatever other `foo_vector_type` is declared. They'll be different types, and 
conditioning behavior on which one you've got is essentially a way to make it 
target-specific.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009

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


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-08-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

In D85009#2187643 , @jfb wrote:

> Language-wise I think https://wg21.link/p1467 is where C++ is going, and C is 
> taking a similar approach.

That doesn't seem to mention vectors at all. As I said on Friday, I wouldn't 
disagree with the idea that //scalar// bfloat should have consistent semantics 
across compiler targets.

> I'd like to make sure this is well thought out. Not just "the ISA does this, 
> let's do the same". We know other ISAs act differently, and I'm not clear on 
> what the intended behavior will be for people writing C and C++ code.

But C-language bindings for vector subsystems have //always// been strongly 
tied to the capabilities of the ISA. You enable them in the first place by 
including some target-specific header such as `arm_neon.h` or `wmmintrin.h` or 
what have you, and then the available operations are whatever are defined by 
the organization that specified that header.

In this case, `bfloat16x4_t` and `bfloat16x8_t` are type names defined in 
`arm_neon.h`. That header is defined by Arm (in the ACLE spec), and you only 
include it and use its definitions if you know you're targeting the Arm ISA. So 
it makes sense that the available operations should correspond to the things 
you can do efficiently on that ISA.

If you wanted //cross-platform// vector bfloat code, you'd include some other 
header that nobody has defined yet. Or, more likely, you'd just write scalar 
bfloat source code, and rely on the compiler to vectorise it for each target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009

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


[PATCH] D85010: [clang][ARM] Add name-mangling test for direct __fp16 arguments.

2020-08-03 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGed0e4c70c99d: [clang][ARM] Add name-mangling test for direct 
__fp16 arguments. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85010

Files:
  clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp


Index: clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-arm-none-eabi 
-fallow-half-arguments-and-returns %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple aarch64-arm-none-eabi 
-fallow-half-arguments-and-returns %s | FileCheck %s
+
+// Test name-mangling of __fp16 passed directly as a function argument
+// (when that is permitted).
+
+// CHECK: define {{.*}}void @_Z13fp16_argumentDh(half %{{.*}})
+void fp16_argument(__fp16 arg) {}
+
+// Test name-mangling of __fp16 as a return type. The return type of
+// fp16_return itself isn't mentioned in the mangled name, so to test
+// this, we have to pass it a function pointer and make __fp16 the
+// return type of that.
+
+// CHECK: define {{.*}}void @_Z11fp16_returnPFDhvE(half ()* %{{.*}})
+void fp16_return(__fp16 (*func)(void)) {}


Index: clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/fp16-mangle-arg-return.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-arm-none-eabi -fallow-half-arguments-and-returns %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple aarch64-arm-none-eabi -fallow-half-arguments-and-returns %s | FileCheck %s
+
+// Test name-mangling of __fp16 passed directly as a function argument
+// (when that is permitted).
+
+// CHECK: define {{.*}}void @_Z13fp16_argumentDh(half %{{.*}})
+void fp16_argument(__fp16 arg) {}
+
+// Test name-mangling of __fp16 as a return type. The return type of
+// fp16_return itself isn't mentioned in the mangled name, so to test
+// this, we have to pass it a function pointer and make __fp16 the
+// return type of that.
+
+// CHECK: define {{.*}}void @_Z11fp16_returnPFDhvE(half ()* %{{.*}})
+void fp16_return(__fp16 (*func)(void)) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-08-06 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

This discussion seems to have wound down. I'll land this patch tomorrow on the 
strength of @LukeGeeson's review, unless you have strong objections, @jfb?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009

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


[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

2020-08-07 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1d782942500b: [Sema][BFloat] Forbid arithmetic on vectors of 
bfloat. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/arm-bfloat.cpp


Index: clang/test/Sema/arm-bfloat.cpp
===
--- clang/test/Sema/arm-bfloat.cpp
+++ clang/test/Sema/arm-bfloat.cpp
@@ -27,3 +27,21 @@
   fp16 = bf16; // expected-error {{assigning to '__fp16' from incompatible 
type '__bf16'}}
   bf16 + (b ? fp16 : bf16); // expected-error {{incompatible operand types 
('__fp16' and '__bf16')}}
 }
+
+#include 
+
+void test_vector(bfloat16x4_t a, bfloat16x4_t b, float16x4_t c) {
+  a + b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a - b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a * b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a / b; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+
+  a + c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a - c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a * c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  a / c; // expected-error {{invalid operands to binary expression 
('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 
4 'float16_t' values))}}
+  c + b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c - b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c * b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+  c / b; // expected-error {{invalid operands to binary expression 
('float16x4_t' (vector of 4 'float16_t' values) and 'bfloat16x4_t' (vector of 4 
'bfloat16_t' values))}}
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -9789,6 +9789,10 @@
   const VectorType *RHSVecType = RHSType->getAs();
   assert(LHSVecType || RHSVecType);
 
+  if ((LHSVecType && LHSVecType->getElementType()->isBFloat16Type()) ||
+  (RHSVecType && RHSVecType->getElementType()->isBFloat16Type()))
+return InvalidOperands(Loc, LHS, RHS);
+
   // AltiVec-style "vector bool op vector bool" combinations are allowed
   // for some operators but not others.
   if (!AllowBothBool &&


Index: clang/test/Sema/arm-bfloat.cpp
===
--- clang/test/Sema/arm-bfloat.cpp
+++ clang/test/Sema/arm-bfloat.cpp
@@ -27,3 +27,21 @@
   fp16 = bf16; // expected-error {{assigning to '__fp16' from incompatible type '__bf16'}}
   bf16 + (b ? fp16 : bf16); // expected-error {{incompatible operand types ('__fp16' and '__bf16')}}
 }
+
+#include 
+
+void test_vector(bfloat16x4_t a, bfloat16x4_t b, float16x4_t c) {
+  a + b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a - b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a * b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+  a / b; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'bfloat16x4_t')}}
+
+  a + c; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 4 'float16_t' values))}}
+  a - c; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 4 'float16_t' values))}}
+  a * c; // expected-error {{invalid operands to binary expression ('bfloat16x4_t' (vector of 4 'bfloat16_t' values) and 'float16x4_t' (vector of 4 'float16_t' values

[PATCH] D12669: [libcxxabi] Fix alignment of pointers returned by fallback_malloc

2022-07-01 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.
Herald added a project: All.

@EricWF, I have an updated version of this patch that applies against current 
`main`. Do you mind if I commandeer this revision and post my updated patch on 
it?


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

https://reviews.llvm.org/D12669

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


[PATCH] D131555: [Clang] Propagate const context info when emitting compound literal

2022-08-10 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

The clang code change looks reasonable to me, but I'm not the most expert in 
that area.

The intended result certainly seems sensible, because the C90-compatible 
version of that code //without// a constant literal is happy to do double→float 
conversion at compile time without complaining about side effects:

  static const float separate_array[1] = { 0.1, };
  struct { const float *floats; } without_compound_literal = { separate_array };

and so it makes sense that the version with a compound literal should be 
treated no differently.

Nit in the commit message:

> which should be in effect yet

Surely "which //shouldn't// be in effect yet"?




Comment at: clang/test/CodeGen/const-init.c:1
-// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion -emit-llvm -o - %s 
| FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion 
-ffp-exception-behavior=strict -emit-llvm -o - %s | FileCheck %s
 

I think some kind of a comment would be useful saying what this option is doing 
there -- at least, which one of the tests further down the file it's supposed 
to apply to. Otherwise I could easily imagine someone throwing it out again, 
and since the test would pass anyway, not noticing that it's no longer testing 
what it's meant to test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131555

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


[PATCH] D105493: [clang] Change set type used for SourceLocation.

2021-07-19 Thread Simon Tatham via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
simon_tatham marked an inline comment as done.
Closed by commit rGcef56d58dbbb: [clang] Change set type used for 
SourceLocation. (authored by simon_tatham).

Changed prior to commit:
  https://reviews.llvm.org/D105493?vs=356758&id=359756#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105493

Files:
  clang/include/clang/Basic/SourceLocation.h
  clang/include/clang/Lex/Preprocessor.h


Index: clang/include/clang/Lex/Preprocessor.h
===
--- clang/include/clang/Lex/Preprocessor.h
+++ clang/include/clang/Lex/Preprocessor.h
@@ -783,8 +783,7 @@
   /// deserializing from PCH, we don't need to deserialize identifier & macros
   /// just so that we can report that they are unused, we just warn using
   /// the SourceLocations of this set (that will be filled by the ASTReader).
-  /// We are using SmallPtrSet instead of a vector for faster removal.
-  using WarnUnusedMacroLocsTy = llvm::SmallPtrSet;
+  using WarnUnusedMacroLocsTy = llvm::SmallDenseSet;
   WarnUnusedMacroLocsTy WarnUnusedMacroLocs;
 
   /// A "freelist" of MacroArg objects that can be
Index: clang/include/clang/Basic/SourceLocation.h
===
--- clang/include/clang/Basic/SourceLocation.h
+++ clang/include/clang/Basic/SourceLocation.h
@@ -16,7 +16,6 @@
 
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/Support/PointerLikeTypeTraits.h"
 #include 
 #include 
 #include 
@@ -510,20 +509,6 @@
 static void Profile(const clang::SourceLocation &X, FoldingSetNodeID &ID);
   };
 
-  // Teach SmallPtrSet how to handle SourceLocation.
-  template<>
-  struct PointerLikeTypeTraits {
-static constexpr int NumLowBitsAvailable = 0;
-
-static void *getAsVoidPointer(clang::SourceLocation L) {
-  return L.getPtrEncoding();
-}
-
-static clang::SourceLocation getFromVoidPointer(void *P) {
-  return clang::SourceLocation::getFromRawEncoding((unsigned)(uintptr_t)P);
-}
-  };
-
 } // namespace llvm
 
 #endif // LLVM_CLANG_BASIC_SOURCELOCATION_H


Index: clang/include/clang/Lex/Preprocessor.h
===
--- clang/include/clang/Lex/Preprocessor.h
+++ clang/include/clang/Lex/Preprocessor.h
@@ -783,8 +783,7 @@
   /// deserializing from PCH, we don't need to deserialize identifier & macros
   /// just so that we can report that they are unused, we just warn using
   /// the SourceLocations of this set (that will be filled by the ASTReader).
-  /// We are using SmallPtrSet instead of a vector for faster removal.
-  using WarnUnusedMacroLocsTy = llvm::SmallPtrSet;
+  using WarnUnusedMacroLocsTy = llvm::SmallDenseSet;
   WarnUnusedMacroLocsTy WarnUnusedMacroLocs;
 
   /// A "freelist" of MacroArg objects that can be
Index: clang/include/clang/Basic/SourceLocation.h
===
--- clang/include/clang/Basic/SourceLocation.h
+++ clang/include/clang/Basic/SourceLocation.h
@@ -16,7 +16,6 @@
 
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/Support/PointerLikeTypeTraits.h"
 #include 
 #include 
 #include 
@@ -510,20 +509,6 @@
 static void Profile(const clang::SourceLocation &X, FoldingSetNodeID &ID);
   };
 
-  // Teach SmallPtrSet how to handle SourceLocation.
-  template<>
-  struct PointerLikeTypeTraits {
-static constexpr int NumLowBitsAvailable = 0;
-
-static void *getAsVoidPointer(clang::SourceLocation L) {
-  return L.getPtrEncoding();
-}
-
-static clang::SourceLocation getFromVoidPointer(void *P) {
-  return clang::SourceLocation::getFromRawEncoding((unsigned)(uintptr_t)P);
-}
-  };
-
 } // namespace llvm
 
 #endif // LLVM_CLANG_BASIC_SOURCELOCATION_H
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

I looked into this yesterday, and realised that I don't actually know what the 
use case //is// for emitting `!srcloc` metadata in an IR file.

It's more or less ignored by llc, as far as I can see: if there's a 
late-breaking error in the inline asm string, you just get a "note: !srcloc = 
" alongside the main error.

And if the IR file is read back in by a second invocation of clang, then the 
frontend callback //does// get the !srcloc back from the IR, but it can't 
relate that to the original source code, because the new clang's SourceManager 
doesn't know anything about the C source files that the IR was made from. In 
the example test I just did by hand, the error message cites a location in the 
IR file that corresponds to the byte position of the error in the original C, 
which is more or less useless.

So I think this mechanism is only actually useful when the whole compilation is 
happening within a single invocation of clang, so that the !srcloc finds its 
way back to a SourceManager that still has all the actual source code in mind. 
As soon as IR files are exported and re-imported, the best we can hope for is 
"no crash".

But I can add a couple of tests along those lines for i32 and i64 versions of 
!srcloc, if that's helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 360098.
simon_tatham edited the summary of this revision.
simon_tatham added a comment.

Added an i64 `!srcloc` to the only existing test of them I could find.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

Files:
  clang/lib/CodeGen/CGStmt.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/LLVMContext.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
  llvm/lib/CodeGen/MachineInstr.cpp
  llvm/lib/IR/LLVMContext.cpp
  llvm/test/MC/ARM/inline-asm-srcloc.ll

Index: llvm/test/MC/ARM/inline-asm-srcloc.ll
===
--- llvm/test/MC/ARM/inline-asm-srcloc.ll
+++ llvm/test/MC/ARM/inline-asm-srcloc.ll
@@ -20,6 +20,8 @@
 ; CHECK: note: !srcloc = 181
   call void asm sideeffect " .word -foo", ""() #1, !srcloc !5
 ; CHECK: note: !srcloc = 257
+  call void asm sideeffect " .word -stoat", ""() #1, !srcloc !6
+; CHECK: note: !srcloc = 534
   ret void
 }
 
@@ -35,3 +37,4 @@
 !3 = !{i32 107}
 !4 = !{i32 181}
 !5 = !{i32 257}
+!6 = !{i64 534}
Index: llvm/lib/IR/LLVMContext.cpp
===
--- llvm/lib/IR/LLVMContext.cpp
+++ llvm/lib/IR/LLVMContext.cpp
@@ -248,7 +248,7 @@
 exit(1);
 }
 
-void LLVMContext::emitError(unsigned LocCookie, const Twine &ErrorStr) {
+void LLVMContext::emitError(uint64_t LocCookie, const Twine &ErrorStr) {
   diagnose(DiagnosticInfoInlineAsm(LocCookie, ErrorStr));
 }
 
Index: llvm/lib/CodeGen/MachineInstr.cpp
===
--- llvm/lib/CodeGen/MachineInstr.cpp
+++ llvm/lib/CodeGen/MachineInstr.cpp
@@ -2083,7 +2083,7 @@
 
 void MachineInstr::emitError(StringRef Msg) const {
   // Find the source location cookie.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = getNumOperands(); i != 0; --i) {
 if (getOperand(i-1).isMetadata() &&
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -130,7 +130,7 @@
 
 static void EmitMSInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
MachineModuleInfo *MMI, AsmPrinter *AP,
-   unsigned LocCookie, raw_ostream &OS) {
+   uint64_t LocCookie, raw_ostream &OS) {
   // Switch to the inline assembly variant.
   OS << "\t.intel_syntax\n\t";
 
@@ -272,7 +272,7 @@
 
 static void EmitGCCInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
 MachineModuleInfo *MMI, const MCAsmInfo *MAI,
-AsmPrinter *AP, unsigned LocCookie,
+AsmPrinter *AP, uint64_t LocCookie,
 raw_ostream &OS) {
   int CurVariant = -1;// The number of the {.|.|.} region we are in.
   const char *LastEmitted = AsmStr; // One past the last character emitted.
@@ -483,7 +483,7 @@
 
   // Get the !srcloc metadata node if we have it, and decode the loc cookie from
   // it.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = MI->getNumOperands(); i != 0; --i) {
 if (MI->getOperand(i-1).isMetadata() &&
Index: llvm/include/llvm/IR/LLVMContext.h
===
--- llvm/include/llvm/IR/LLVMContext.h
+++ llvm/include/llvm/IR/LLVMContext.h
@@ -290,7 +290,7 @@
   /// be prepared to drop the erroneous construct on the floor and "not crash".
   /// The generated code need not be correct.  The error message will be
   /// implicitly prefixed with "error: " and should not end with a ".".
-  void emitError(unsigned LocCookie, const Twine &ErrorStr);
+  void emitError(uint64_t LocCookie, const Twine &ErrorStr);
   void emitError(const Instruction *I, const Twine &ErrorStr);
   void emitError(const Twine &ErrorStr);
 
Index: llvm/include/llvm/IR/DiagnosticInfo.h
===
--- llvm/include/llvm/IR/DiagnosticInfo.h
+++ llvm/include/llvm/IR/DiagnosticInfo.h
@@ -131,7 +131,7 @@
 class DiagnosticInfoInlineAsm : public DiagnosticInfo {
 private:
   /// Optional line information. 0 if not set.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   /// Message to be reported.
   const Twine &MsgStr;
   /// Optional origin of the problem.
@@ -149,7 +149,7 @@
   /// \p MsgStr gives the message.
   /// This class does not copy \p MsgStr, therefore the reference must be valid
   /// for the whole life time of the Diagnostic.
-  DiagnosticInfoInlineAsm(unsigned LocCookie, const Twine &MsgStr,
+  DiagnosticInfoInlineAsm(uint64_t LocCookie, const Twine &MsgStr,
   

[PATCH] D105492: [clang] Introduce SourceLocation::[U]IntTy typedefs.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 360099.
simon_tatham retitled this revision from "[clang] Introduce 
SourceLocation::[U]IntType typedefs." to "[clang] Introduce 
SourceLocation::[U]IntTy typedefs.".
simon_tatham added a comment.

Renamed types to [U]IntTy. This will affect some of the dependent patches too, 
but I agree that saving two characters is worthwhile – these names are long 
enough already :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105492

Files:
  clang/include/clang/AST/DeclarationName.h
  clang/include/clang/Basic/SourceLocation.h
  clang/include/clang/Basic/SourceManager.h
  clang/include/clang/Lex/Token.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/ARCMigrate/TransEmptyStatementsAndDealloc.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Lex/PPCaching.cpp
  clang/lib/Lex/TokenLexer.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1983,7 +1983,8 @@
 return static_cast(data[0]);
   }
   SourceLocation getLoc() const {
-return SourceLocation::getFromRawEncoding((unsigned)(uintptr_t)data[1]);
+return SourceLocation::getFromRawEncoding(
+(SourceLocation::UIntTy)(uintptr_t)data[1]);
   }
 };
 class EnqueueVisitor : public ConstStmtVisitor {
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -2041,7 +2041,7 @@
   Record.push_back(Expansion.isExpansionTokenRange());
 
   // Compute the token length for this macro expansion.
-  unsigned NextOffset = SourceMgr.getNextLocalOffset();
+  SourceLocation::UIntTy NextOffset = SourceMgr.getNextLocalOffset();
   if (I + 1 != N)
 NextOffset = SourceMgr.getLocalSLocEntry(I + 1).getOffset();
   Record.push_back(NextOffset - SLoc->getOffset() - 1);
@@ -4640,7 +4640,7 @@
 // another module after it or have more than one entity inside it.
 uint32_t None = std::numeric_limits::max();
 
-auto writeBaseIDOrNone = [&](uint32_t BaseID, bool ShouldWrite) {
+auto writeBaseIDOrNone = [&](auto BaseID, bool ShouldWrite) {
   assert(BaseID < std::numeric_limits::max() && "base id too high");
   if (ShouldWrite)
 LE.write(BaseID);
@@ -5027,8 +5027,8 @@
 }
 
 void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
-  uint32_t Raw = Loc.getRawEncoding();
-  Record.push_back((Raw << 1) | (Raw >> 31));
+  SourceLocation::UIntTy Raw = Loc.getRawEncoding();
+  Record.push_back((Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1)));
 }
 
 void ASTWriter::AddSourceRange(SourceRange Range, RecordDataImpl &Record) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -1482,7 +1482,7 @@
   }
 
   BitstreamCursor &SLocEntryCursor = F->SLocEntryCursor;
-  unsigned BaseOffset = F->SLocEntryBaseOffset;
+  SourceLocation::UIntTy BaseOffset = F->SLocEntryBaseOffset;
 
   ++NumSLocEntriesRead;
   Expected MaybeEntry = SLocEntryCursor.advance();
@@ -3409,7 +3409,7 @@
 case SOURCE_LOCATION_OFFSETS: {
   F.SLocEntryOffsets = (const uint32_t *)Blob.data();
   F.LocalNumSLocEntries = Record[0];
-  unsigned SLocSpaceSize = Record[1];
+  SourceLocation::UIntTy SLocSpaceSize = Record[1];
   F.SLocEntryOffsetsBase = Record[2] + F.SourceManagerBlockStartOffset;
   std::tie(F.SLocEntryBaseID, F.SLocEntryBaseOffset) =
   SourceMgr.AllocateLoadedSLocEntries(F.LocalNumSLocEntries,
@@ -3427,7 +3427,7 @@
   F.FirstLoc = SourceLocation::getFromRawEncoding(F.SLocEntryBaseOffset);
 
   // SLocEntryBaseOffset is lower than MaxLoadedOffset and decreasing.
-  assert((F.SLocEntryBaseOffset & (1U << 31U)) == 0);
+  assert((F.SLocEntryBaseOffset & SourceLocation::MacroIDBit) == 0);
   GlobalSLocOffsetMap.insert(
   std::make_pair(SourceManager::MaxLoadedOffset - F.SLocEntryBaseOffset
- SLocSpaceSize,&F));
@@ -3436,8 +3436,8 @@
   // Invalid stays invalid.
   F.SLocRemap.insertOrReplace(std::make_pair(0U, 0));
   // This module. Base was 2 when being compiled.
-  F.SLocRemap.insertOrReplace(std::make_pair(2U,
- 

[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 360101.
simon_tatham edited the summary of this revision.
simon_tatham added a comment.

Split up the allocations as suggested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/lib/AST/DeclObjC.cpp

Index: clang/lib/AST/DeclObjC.cpp
===
--- clang/lib/AST/DeclObjC.cpp
+++ clang/lib/AST/DeclObjC.cpp
@@ -28,6 +28,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -867,21 +868,21 @@
 }
 
 void ObjCMethodDecl::setParamsAndSelLocs(ASTContext &C,
- ArrayRef Params,
- ArrayRef SelLocs) {
-  ParamsAndSelLocs = nullptr;
-  NumParams = Params.size();
-  if (Params.empty() && SelLocs.empty())
-return;
-
-  static_assert(alignof(ParmVarDecl *) >= alignof(SourceLocation),
-"Alignment not sufficient for SourceLocation");
+ ArrayRef ParamsIn,
+ ArrayRef SelLocsIn) {
+  Params = nullptr;
+  NumParams = ParamsIn.size();
+  SelLocs = nullptr;
+
+  if (!ParamsIn.empty()) {
+Params = C.Allocate(ParamsIn.size());
+std::copy(ParamsIn.begin(), ParamsIn.end(), Params);
+  }
 
-  unsigned Size = sizeof(ParmVarDecl *) * NumParams +
-  sizeof(SourceLocation) * SelLocs.size();
-  ParamsAndSelLocs = C.Allocate(Size);
-  std::copy(Params.begin(), Params.end(), getParams());
-  std::copy(SelLocs.begin(), SelLocs.end(), getStoredSelLocs());
+  if (!SelLocsIn.empty()) {
+SelLocs = C.Allocate(SelLocsIn.size());
+std::copy(SelLocsIn.begin(), SelLocsIn.end(), SelLocs);
+  }
 }
 
 void ObjCMethodDecl::getSelectorLocs(
Index: clang/include/clang/AST/DeclObjC.h
===
--- clang/include/clang/AST/DeclObjC.h
+++ clang/include/clang/AST/DeclObjC.h
@@ -150,11 +150,13 @@
   /// Type source information for the return type.
   TypeSourceInfo *ReturnTInfo;
 
-  /// Array of ParmVarDecls for the formal parameters of this method
-  /// and optionally followed by selector locations.
-  void *ParamsAndSelLocs = nullptr;
+  /// Array of the formal parameters of this method.
+  ParmVarDecl **Params = nullptr;
   unsigned NumParams = 0;
 
+  /// Source locations for the selector identifiers.
+  SourceLocation *SelLocs = nullptr;
+
   /// List of attributes for this method declaration.
   SourceLocation DeclEndLoc; // the location of the ';' or '{'.
 
@@ -190,22 +192,20 @@
 return getSelLocsKind() != SelLoc_NonStandard;
   }
 
-  /// Get a pointer to the stored selector identifiers locations array.
-  /// No locations will be stored if HasStandardSelLocs is true.
-  SourceLocation *getStoredSelLocs() {
-return reinterpret_cast(getParams() + NumParams);
-  }
-  const SourceLocation *getStoredSelLocs() const {
-return reinterpret_cast(getParams() + NumParams);
+  size_t getStoredSelLocsOffset() const {
+return llvm::alignTo(sizeof(ParmVarDecl *) *
+  NumParams);
   }
 
   /// Get a pointer to the stored selector identifiers locations array.
   /// No locations will be stored if HasStandardSelLocs is true.
-  ParmVarDecl **getParams() {
-return reinterpret_cast(ParamsAndSelLocs);
-  }
+  SourceLocation *getStoredSelLocs() { return SelLocs; }
+  const SourceLocation *getStoredSelLocs() const { return SelLocs; }
+
+  /// Get a pointer to the parameter array.
+  ParmVarDecl **getParams() { return Params; }
   const ParmVarDecl *const *getParams() const {
-return reinterpret_cast(ParamsAndSelLocs);
+return const_cast(Params);
   }
 
   /// Get the number of stored selector identifiers locations.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 360104.
simon_tatham added a comment.

... and removed an unused function from the previous version.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/lib/AST/DeclObjC.cpp


Index: clang/lib/AST/DeclObjC.cpp
===
--- clang/lib/AST/DeclObjC.cpp
+++ clang/lib/AST/DeclObjC.cpp
@@ -28,6 +28,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -867,21 +868,21 @@
 }
 
 void ObjCMethodDecl::setParamsAndSelLocs(ASTContext &C,
- ArrayRef Params,
- ArrayRef SelLocs) {
-  ParamsAndSelLocs = nullptr;
-  NumParams = Params.size();
-  if (Params.empty() && SelLocs.empty())
-return;
-
-  static_assert(alignof(ParmVarDecl *) >= alignof(SourceLocation),
-"Alignment not sufficient for SourceLocation");
+ ArrayRef ParamsIn,
+ ArrayRef SelLocsIn) {
+  Params = nullptr;
+  NumParams = ParamsIn.size();
+  SelLocs = nullptr;
+
+  if (!ParamsIn.empty()) {
+Params = C.Allocate(ParamsIn.size());
+std::copy(ParamsIn.begin(), ParamsIn.end(), Params);
+  }
 
-  unsigned Size = sizeof(ParmVarDecl *) * NumParams +
-  sizeof(SourceLocation) * SelLocs.size();
-  ParamsAndSelLocs = C.Allocate(Size);
-  std::copy(Params.begin(), Params.end(), getParams());
-  std::copy(SelLocs.begin(), SelLocs.end(), getStoredSelLocs());
+  if (!SelLocsIn.empty()) {
+SelLocs = C.Allocate(SelLocsIn.size());
+std::copy(SelLocsIn.begin(), SelLocsIn.end(), SelLocs);
+  }
 }
 
 void ObjCMethodDecl::getSelectorLocs(
Index: clang/include/clang/AST/DeclObjC.h
===
--- clang/include/clang/AST/DeclObjC.h
+++ clang/include/clang/AST/DeclObjC.h
@@ -150,11 +150,13 @@
   /// Type source information for the return type.
   TypeSourceInfo *ReturnTInfo;
 
-  /// Array of ParmVarDecls for the formal parameters of this method
-  /// and optionally followed by selector locations.
-  void *ParamsAndSelLocs = nullptr;
+  /// Array of the formal parameters of this method.
+  ParmVarDecl **Params = nullptr;
   unsigned NumParams = 0;
 
+  /// Source locations for the selector identifiers.
+  SourceLocation *SelLocs = nullptr;
+
   /// List of attributes for this method declaration.
   SourceLocation DeclEndLoc; // the location of the ';' or '{'.
 
@@ -192,20 +194,13 @@
 
   /// Get a pointer to the stored selector identifiers locations array.
   /// No locations will be stored if HasStandardSelLocs is true.
-  SourceLocation *getStoredSelLocs() {
-return reinterpret_cast(getParams() + NumParams);
-  }
-  const SourceLocation *getStoredSelLocs() const {
-return reinterpret_cast(getParams() + NumParams);
-  }
+  SourceLocation *getStoredSelLocs() { return SelLocs; }
+  const SourceLocation *getStoredSelLocs() const { return SelLocs; }
 
-  /// Get a pointer to the stored selector identifiers locations array.
-  /// No locations will be stored if HasStandardSelLocs is true.
-  ParmVarDecl **getParams() {
-return reinterpret_cast(ParamsAndSelLocs);
-  }
+  /// Get a pointer to the parameter array.
+  ParmVarDecl **getParams() { return Params; }
   const ParmVarDecl *const *getParams() const {
-return reinterpret_cast(ParamsAndSelLocs);
+return const_cast(Params);
   }
 
   /// Get the number of stored selector identifiers locations.


Index: clang/lib/AST/DeclObjC.cpp
===
--- clang/lib/AST/DeclObjC.cpp
+++ clang/lib/AST/DeclObjC.cpp
@@ -28,6 +28,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -867,21 +868,21 @@
 }
 
 void ObjCMethodDecl::setParamsAndSelLocs(ASTContext &C,
- ArrayRef Params,
- ArrayRef SelLocs) {
-  ParamsAndSelLocs = nullptr;
-  NumParams = Params.size();
-  if (Params.empty() && SelLocs.empty())
-return;
-
-  static_assert(alignof(ParmVarDecl *) >= alignof(SourceLocation),
-"Alignment not sufficient for SourceLocation");
+ ArrayRef ParamsIn,
+ ArrayRef SelLocsIn) {
+  Params = nullptr;
+  NumParams = ParamsIn.size();
+  SelLocs = nullptr;
+
+  if (!ParamsIn.empty()) {
+Params = C.Allocate(ParamsIn.size());
+std::copy(ParamsIn.begin(), ParamsIn.end(), Params

[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/lib/AST/DeclObjC.cpp:31
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"

Oops, before anyone else points it out, this `#include` is also now unnecessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

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


[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/include/clang/AST/DeclObjC.h:208
   const ParmVarDecl *const *getParams() const {
-return reinterpret_cast(ParamsAndSelLocs);
+return const_cast(Params);
   }

tmatheson wrote:
> I don't think you need the `const_cast`
I put it in because I got a compile error otherwise!

It's because of the double indirection. You don't need a cast to turn a `Foo *` 
into a `const Foo *`. But here, we're turning a `Foo *` into a `const Bar *`, 
where `Foo` and `Bar` are pointer types to things of different constness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

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


[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 360123.
simon_tatham added a comment.

Addressed two nits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/lib/AST/DeclObjC.cpp


Index: clang/lib/AST/DeclObjC.cpp
===
--- clang/lib/AST/DeclObjC.cpp
+++ clang/lib/AST/DeclObjC.cpp
@@ -867,21 +867,21 @@
 }
 
 void ObjCMethodDecl::setParamsAndSelLocs(ASTContext &C,
- ArrayRef Params,
- ArrayRef SelLocs) {
-  ParamsAndSelLocs = nullptr;
-  NumParams = Params.size();
-  if (Params.empty() && SelLocs.empty())
-return;
-
-  static_assert(alignof(ParmVarDecl *) >= alignof(SourceLocation),
-"Alignment not sufficient for SourceLocation");
+ ArrayRef ParamsIn,
+ ArrayRef SelLocsIn) {
+  Params = nullptr;
+  NumParams = ParamsIn.size();
+  SelLocs = nullptr;
+
+  if (!ParamsIn.empty()) {
+Params = C.Allocate(ParamsIn.size());
+std::copy(ParamsIn.begin(), ParamsIn.end(), Params);
+  }
 
-  unsigned Size = sizeof(ParmVarDecl *) * NumParams +
-  sizeof(SourceLocation) * SelLocs.size();
-  ParamsAndSelLocs = C.Allocate(Size);
-  std::copy(Params.begin(), Params.end(), getParams());
-  std::copy(SelLocs.begin(), SelLocs.end(), getStoredSelLocs());
+  if (!SelLocsIn.empty()) {
+SelLocs = C.Allocate(SelLocsIn.size());
+std::copy(SelLocsIn.begin(), SelLocsIn.end(), SelLocs);
+  }
 }
 
 void ObjCMethodDecl::getSelectorLocs(
Index: clang/include/clang/AST/DeclObjC.h
===
--- clang/include/clang/AST/DeclObjC.h
+++ clang/include/clang/AST/DeclObjC.h
@@ -150,11 +150,13 @@
   /// Type source information for the return type.
   TypeSourceInfo *ReturnTInfo;
 
-  /// Array of ParmVarDecls for the formal parameters of this method
-  /// and optionally followed by selector locations.
-  void *ParamsAndSelLocs = nullptr;
+  /// Array of the formal parameters of this method.
+  ParmVarDecl **Params = nullptr;
   unsigned NumParams = 0;
 
+  /// Source locations for the selector identifiers.
+  SourceLocation *SelLocs = nullptr;
+
   /// List of attributes for this method declaration.
   SourceLocation DeclEndLoc; // the location of the ';' or '{'.
 
@@ -192,21 +194,12 @@
 
   /// Get a pointer to the stored selector identifiers locations array.
   /// No locations will be stored if HasStandardSelLocs is true.
-  SourceLocation *getStoredSelLocs() {
-return reinterpret_cast(getParams() + NumParams);
-  }
-  const SourceLocation *getStoredSelLocs() const {
-return reinterpret_cast(getParams() + NumParams);
-  }
+  SourceLocation *getStoredSelLocs() { return SelLocs; }
+  const SourceLocation *getStoredSelLocs() const { return SelLocs; }
 
-  /// Get a pointer to the stored selector identifiers locations array.
-  /// No locations will be stored if HasStandardSelLocs is true.
-  ParmVarDecl **getParams() {
-return reinterpret_cast(ParamsAndSelLocs);
-  }
-  const ParmVarDecl *const *getParams() const {
-return reinterpret_cast(ParamsAndSelLocs);
-  }
+  /// Get a pointer to the parameter array.
+  ParmVarDecl **getParams() { return Params; }
+  const ParmVarDecl *const *getParams() const { return Params; }
 
   /// Get the number of stored selector identifiers locations.
   /// No locations will be stored if HasStandardSelLocs is true.


Index: clang/lib/AST/DeclObjC.cpp
===
--- clang/lib/AST/DeclObjC.cpp
+++ clang/lib/AST/DeclObjC.cpp
@@ -867,21 +867,21 @@
 }
 
 void ObjCMethodDecl::setParamsAndSelLocs(ASTContext &C,
- ArrayRef Params,
- ArrayRef SelLocs) {
-  ParamsAndSelLocs = nullptr;
-  NumParams = Params.size();
-  if (Params.empty() && SelLocs.empty())
-return;
-
-  static_assert(alignof(ParmVarDecl *) >= alignof(SourceLocation),
-"Alignment not sufficient for SourceLocation");
+ ArrayRef ParamsIn,
+ ArrayRef SelLocsIn) {
+  Params = nullptr;
+  NumParams = ParamsIn.size();
+  SelLocs = nullptr;
+
+  if (!ParamsIn.empty()) {
+Params = C.Allocate(ParamsIn.size());
+std::copy(ParamsIn.begin(), ParamsIn.end(), Params);
+  }
 
-  unsigned Size = sizeof(ParmVarDecl *) * NumParams +
-  sizeof(SourceLocation) * SelLocs.size();
-  ParamsAndSelLocs = C.Allocate(Size);
-  std::copy(Params.begin(), Params.end(), getParams());
-  std::copy(SelLocs.begin(), SelLocs.end(), getStoredSelLocs());
+  if (!SelLocsIn.empty()) {
+SelLocs = C.Allocate(SelLocsIn.size());
+std::copy(SelLocsIn.begin(), Se

[PATCH] D105498: [clang] Remove assumption about SourceLocation alignment.

2021-07-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/include/clang/AST/DeclObjC.h:208
   const ParmVarDecl *const *getParams() const {
-return reinterpret_cast(ParamsAndSelLocs);
+return const_cast(Params);
   }

simon_tatham wrote:
> tmatheson wrote:
> > I don't think you need the `const_cast`
> I put it in because I got a compile error otherwise!
> 
> It's because of the double indirection. You don't need a cast to turn a `Foo 
> *` into a `const Foo *`. But here, we're turning a `Foo *` into a `const Bar 
> *`, where `Foo` and `Bar` are pointer types to things of different constness.
... ok, no, removing the `const_cast` now, I don't get a compile error. In that 
case there must have been something else weird about the version of the code 
where I had to add it, but I can't reconstruct what.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105498

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


[PATCH] D105492: [clang] Introduce SourceLocation::[U]IntTy typedefs.

2021-07-21 Thread Simon Tatham via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG21401a72629c: [clang] Introduce SourceLocation::[U]IntTy 
typedefs. (authored by simon_tatham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105492

Files:
  clang/include/clang/AST/DeclarationName.h
  clang/include/clang/Basic/SourceLocation.h
  clang/include/clang/Basic/SourceManager.h
  clang/include/clang/Lex/Token.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/ARCMigrate/TransEmptyStatementsAndDealloc.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Lex/PPCaching.cpp
  clang/lib/Lex/TokenLexer.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1983,7 +1983,8 @@
 return static_cast(data[0]);
   }
   SourceLocation getLoc() const {
-return SourceLocation::getFromRawEncoding((unsigned)(uintptr_t)data[1]);
+return SourceLocation::getFromRawEncoding(
+(SourceLocation::UIntTy)(uintptr_t)data[1]);
   }
 };
 class EnqueueVisitor : public ConstStmtVisitor {
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -2041,7 +2041,7 @@
   Record.push_back(Expansion.isExpansionTokenRange());
 
   // Compute the token length for this macro expansion.
-  unsigned NextOffset = SourceMgr.getNextLocalOffset();
+  SourceLocation::UIntTy NextOffset = SourceMgr.getNextLocalOffset();
   if (I + 1 != N)
 NextOffset = SourceMgr.getLocalSLocEntry(I + 1).getOffset();
   Record.push_back(NextOffset - SLoc->getOffset() - 1);
@@ -4640,7 +4640,7 @@
 // another module after it or have more than one entity inside it.
 uint32_t None = std::numeric_limits::max();
 
-auto writeBaseIDOrNone = [&](uint32_t BaseID, bool ShouldWrite) {
+auto writeBaseIDOrNone = [&](auto BaseID, bool ShouldWrite) {
   assert(BaseID < std::numeric_limits::max() && "base id too high");
   if (ShouldWrite)
 LE.write(BaseID);
@@ -5027,8 +5027,8 @@
 }
 
 void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
-  uint32_t Raw = Loc.getRawEncoding();
-  Record.push_back((Raw << 1) | (Raw >> 31));
+  SourceLocation::UIntTy Raw = Loc.getRawEncoding();
+  Record.push_back((Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1)));
 }
 
 void ASTWriter::AddSourceRange(SourceRange Range, RecordDataImpl &Record) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -1482,7 +1482,7 @@
   }
 
   BitstreamCursor &SLocEntryCursor = F->SLocEntryCursor;
-  unsigned BaseOffset = F->SLocEntryBaseOffset;
+  SourceLocation::UIntTy BaseOffset = F->SLocEntryBaseOffset;
 
   ++NumSLocEntriesRead;
   Expected MaybeEntry = SLocEntryCursor.advance();
@@ -3409,7 +3409,7 @@
 case SOURCE_LOCATION_OFFSETS: {
   F.SLocEntryOffsets = (const uint32_t *)Blob.data();
   F.LocalNumSLocEntries = Record[0];
-  unsigned SLocSpaceSize = Record[1];
+  SourceLocation::UIntTy SLocSpaceSize = Record[1];
   F.SLocEntryOffsetsBase = Record[2] + F.SourceManagerBlockStartOffset;
   std::tie(F.SLocEntryBaseID, F.SLocEntryBaseOffset) =
   SourceMgr.AllocateLoadedSLocEntries(F.LocalNumSLocEntries,
@@ -3427,7 +3427,7 @@
   F.FirstLoc = SourceLocation::getFromRawEncoding(F.SLocEntryBaseOffset);
 
   // SLocEntryBaseOffset is lower than MaxLoadedOffset and decreasing.
-  assert((F.SLocEntryBaseOffset & (1U << 31U)) == 0);
+  assert((F.SLocEntryBaseOffset & SourceLocation::MacroIDBit) == 0);
   GlobalSLocOffsetMap.insert(
   std::make_pair(SourceManager::MaxLoadedOffset - F.SLocEntryBaseOffset
- SLocSpaceSize,&F));
@@ -3436,8 +3436,8 @@
   // Invalid stays invalid.
   F.SLocRemap.insertOrReplace(std::make_pair(0U, 0));
   // This module. Base was 2 when being compiled.
-  F.SLocRemap.insertOrReplace(std::make_pair(2U,
-  static_cast(F.SLocEntryBaseOffset - 2)));
+  F.SLocRemap.insertOrReplace(std::make_pair(
+  2U, static_cast(F.SLocEntryBaseOffset - 

[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-21 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a subscriber: lattner.
simon_tatham added a comment.

In D105491#2891860 , @dexonsmith 
wrote:

> although it'd be good to get someone more involved in lib/CodeGen to take a 
> quick look / sign off (ideally someone that knows the use case for 
> `!srcloc`...).

Any idea who that might be? Looking through the logs, @lattner seems to have 
made all the commits that set up `!srcloc` in the first place, and nobody seems 
to have modified the mechanism much since then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

@lattner, thanks for the help. In this case, the real question is whether 
there's any use case for `!srcloc` that involves writing it out into a bitcode 
or IR file and then having a separate instance of clang load it back in again.

I think that no such case can possibly give a useful mapping back to the 
original source, because IR doesn't serialise the SourceManager that knows how 
to turn source locations back into a useful error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
simon_tatham marked an inline comment as done.
Closed by commit rGbd41136746a0: [clang] Use i64 for the !srcloc metadata on 
asm IR nodes. (authored by simon_tatham).

Changed prior to commit:
  https://reviews.llvm.org/D105491?vs=360098&id=360743#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

Files:
  clang/lib/CodeGen/CGStmt.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/LLVMContext.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
  llvm/lib/CodeGen/MachineInstr.cpp
  llvm/lib/IR/LLVMContext.cpp
  llvm/test/MC/ARM/inline-asm-srcloc.ll

Index: llvm/test/MC/ARM/inline-asm-srcloc.ll
===
--- llvm/test/MC/ARM/inline-asm-srcloc.ll
+++ llvm/test/MC/ARM/inline-asm-srcloc.ll
@@ -20,6 +20,8 @@
 ; CHECK: note: !srcloc = 181
   call void asm sideeffect " .word -foo", ""() #1, !srcloc !5
 ; CHECK: note: !srcloc = 257
+  call void asm sideeffect " .word -stoat", ""() #1, !srcloc !6
+; CHECK: note: !srcloc = 534
   ret void
 }
 
@@ -33,5 +35,11 @@
 !1 = !{i32 1, !"min_enum_size", i32 4}
 !2 = !{!"clang version 5.0.0 "}
 !3 = !{i32 107}
+
+; These !srcloc metadata nodes are intentionally not all the same type: D105491
+; changed the creation of !srcloc to generate i64 instead of the previous i32.
+; So one thing we're testing here is that both types are acceptable on input,
+; i.e. IR generated both before and after the change can be consumed.
 !4 = !{i32 181}
 !5 = !{i32 257}
+!6 = !{i64 534}
Index: llvm/lib/IR/LLVMContext.cpp
===
--- llvm/lib/IR/LLVMContext.cpp
+++ llvm/lib/IR/LLVMContext.cpp
@@ -248,7 +248,7 @@
 exit(1);
 }
 
-void LLVMContext::emitError(unsigned LocCookie, const Twine &ErrorStr) {
+void LLVMContext::emitError(uint64_t LocCookie, const Twine &ErrorStr) {
   diagnose(DiagnosticInfoInlineAsm(LocCookie, ErrorStr));
 }
 
Index: llvm/lib/CodeGen/MachineInstr.cpp
===
--- llvm/lib/CodeGen/MachineInstr.cpp
+++ llvm/lib/CodeGen/MachineInstr.cpp
@@ -2083,7 +2083,7 @@
 
 void MachineInstr::emitError(StringRef Msg) const {
   // Find the source location cookie.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = getNumOperands(); i != 0; --i) {
 if (getOperand(i-1).isMetadata() &&
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -130,7 +130,7 @@
 
 static void EmitMSInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
MachineModuleInfo *MMI, AsmPrinter *AP,
-   unsigned LocCookie, raw_ostream &OS) {
+   uint64_t LocCookie, raw_ostream &OS) {
   // Switch to the inline assembly variant.
   OS << "\t.intel_syntax\n\t";
 
@@ -272,7 +272,7 @@
 
 static void EmitGCCInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
 MachineModuleInfo *MMI, const MCAsmInfo *MAI,
-AsmPrinter *AP, unsigned LocCookie,
+AsmPrinter *AP, uint64_t LocCookie,
 raw_ostream &OS) {
   int CurVariant = -1;// The number of the {.|.|.} region we are in.
   const char *LastEmitted = AsmStr; // One past the last character emitted.
@@ -483,7 +483,7 @@
 
   // Get the !srcloc metadata node if we have it, and decode the loc cookie from
   // it.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = MI->getNumOperands(); i != 0; --i) {
 if (MI->getOperand(i-1).isMetadata() &&
Index: llvm/include/llvm/IR/LLVMContext.h
===
--- llvm/include/llvm/IR/LLVMContext.h
+++ llvm/include/llvm/IR/LLVMContext.h
@@ -290,7 +290,7 @@
   /// be prepared to drop the erroneous construct on the floor and "not crash".
   /// The generated code need not be correct.  The error message will be
   /// implicitly prefixed with "error: " and should not end with a ".".
-  void emitError(unsigned LocCookie, const Twine &ErrorStr);
+  void emitError(uint64_t LocCookie, const Twine &ErrorStr);
   void emitError(const Instruction *I, const Twine &ErrorStr);
   void emitError(const Twine &ErrorStr);
 
Index: llvm/include/llvm/IR/DiagnosticInfo.h
===
--- llvm/include/llvm/IR/DiagnosticInfo.h
+++ llvm/include/llvm/IR/DiagnosticInfo.h
@@ -131,7 +131,7 @@
 class DiagnosticInfoInlineA

[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

(But I've pushed this patch anyway, because I'm reasonably confident of the 
answer; if it turns out that there's some case along those lines that I should 
have taken care of, I'll fix or revert.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[PATCH] D105495: [clang] Make negative getLocWithOffset widening-safe.

2021-07-27 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 361957.
simon_tatham edited the summary of this revision.
simon_tatham added a comment.

In D105495#2882628 , @tmatheson wrote:

> I also think it's the caller's responsibility to make sure what they pass in 
> is correctly signed.

I don't disagree with that in principle, but in a case like this, where the 
error is extremely easy to make, not warned about at compile time (so you have 
to exercise the failing code path to spot it), and won't even show up at 
//runtime// in the default build configuration (even once 64-bit 
SourceLocations are actually implemented, the current plan is for them to be 
off by default), I think it's worth at least //trying// to think of ways to 
help the caller get it right.

Perhaps an alternative API might be to replace 
`SourceLocation::getLocWithOffset` with an `operator+`, and add an `operator-` 
to go with it? Then you could write `NewLoc = OldLoc + ThisInteger - 
ThatInteger` and each integer would be implicitly widened if it was the wrong 
size.

But in this version of the patch, I haven't done that; I've just reverted the 
introduction of dyadic `getLocWithOffset` and added cumbersome casts or 
intermediate variables at the call sites where I'd previously used it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105495

Files:
  clang/lib/AST/SelectorLocationsKind.cpp
  clang/lib/CodeGen/CoverageMappingGen.cpp
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Lex/Lexer.cpp
  clang/lib/Parse/ParseStmtAsm.cpp
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp

Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
@@ -1081,8 +1081,8 @@
   // Highlight the range.  Make the span tag the outermost tag for the
   // selected range.
 
-  SourceLocation E =
-InstantiationEnd.getLocWithOffset(EndColNo - OldEndColNo);
+  SourceLocation E = InstantiationEnd.getLocWithOffset(
+  static_cast(EndColNo) - OldEndColNo);
 
   html::HighlightRange(R, InstantiationStart, E, HighlightStart, HighlightEnd);
 }
Index: clang/lib/Parse/ParseStmtAsm.cpp
===
--- clang/lib/Parse/ParseStmtAsm.cpp
+++ clang/lib/Parse/ParseStmtAsm.cpp
@@ -185,7 +185,8 @@
   if (TokIndex < AsmToks.size()) {
 const Token &Tok = AsmToks[TokIndex];
 Loc = Tok.getLocation();
-Loc = Loc.getLocWithOffset(Offset - TokOffset);
+Loc = Loc.getLocWithOffset(static_cast(Offset) -
+   TokOffset);
   }
   return Loc;
 }
Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -510,24 +510,29 @@
   const SourceManager &SM,
   const LangOptions &LangOpts) {
   assert(Loc.isFileID());
-  std::pair LocInfo = SM.getDecomposedLoc(Loc);
-  if (LocInfo.first.isInvalid())
+  FileID LocFileID;
+  SourceLocation::UIntTy LocOffset;
+  std::tie(LocFileID, LocOffset) = SM.getDecomposedLoc(Loc);
+  if (LocFileID.isInvalid())
 return Loc;
 
   bool Invalid = false;
-  StringRef Buffer = SM.getBufferData(LocInfo.first, &Invalid);
+  StringRef Buffer = SM.getBufferData(LocFileID, &Invalid);
   if (Invalid)
 return Loc;
 
+  if (LocOffset > Buffer.size())
+return Loc;
+
   // Back up from the current location until we hit the beginning of a line
   // (or the buffer). We'll relex from that point.
-  const char *StrData = Buffer.data() + LocInfo.second;
-  const char *LexStart = findBeginningOfLine(Buffer, LocInfo.second);
+  const char *StrData = Buffer.data() + LocOffset;
+  const char *LexStart = findBeginningOfLine(Buffer, LocOffset);
   if (!LexStart || LexStart == StrData)
 return Loc;
 
   // Create a lexer starting at the beginning of this token.
-  SourceLocation LexerStartLoc = Loc.getLocWithOffset(-LocInfo.second);
+  SourceLocation LexerStartLoc = Loc.getLocWithOffset(-LocOffset);
   Lexer TheLexer(LexerStartLoc, LangOpts, Buffer.data(), LexStart,
  Buffer.end());
   TheLexer.SetCommentRetentionState(true);
@@ -565,12 +570,12 @@
 
   SourceLocation FileLoc = SM.getSpellingLoc(Loc);
   SourceLocation BeginFileLoc = getBeginningOfFileToken(FileLoc, SM, LangOpts);
-  std::pair FileLocInfo = SM.getDecomposedLoc(FileLoc);
-  std::pair BeginFileLocInfo =
-  SM.getDecomposedLoc(BeginFileLoc);
-  assert(FileLocInfo.first == BeginFileLocInfo.first &&
- FileLocInfo.second >= BeginFileLocInfo.second);
-  return Loc.getLocWithOffset(BeginFileLocInfo.second - FileLocInfo.second);
+  FileID FID, BeginFID;
+  SourceLocation::UIntTy FileOffset, BeginFileOffset;
+  s

[PATCH] D105495: [clang] Make negative getLocWithOffset widening-safe.

2021-07-27 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:236
 if (Loc.isMacroID())
-  return Loc.getLocWithOffset(-SM.getFileOffset(Loc));
+  return Loc.getLocWithOffset(0, SM.getFileOffset(Loc));
 return SM.getLocForStartOfFile(SM.getFileID(Loc));

tmatheson wrote:
> Seems like getFileOffset should now return ui64.
That seems sensible from first principles, but I tried tugging on that thread 
and it turned out to have a //lot// of extra work behind it, because file 
offsets are absolutely all over the place (perhaps even more so that 
SourceLocations proper), and in particular, they're often used as indexes into 
in-memory buffers, which gets awkward if you want 64-bit SourceLocations and 
64-bit builds of clang to be independent choices.

Perhaps you're right that expanding file offsets to 64-bit would also be a 
useful piece of work. But doing it as part of //this// work would double the 
size of the job, so I think it would make more sense to keep it separate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105495

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


[PATCH] D122046: [clang] Remove Address::deprecated from MveEmitter

2022-03-21 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham accepted this revision.
simon_tatham added a comment.
This revision is now accepted and ready to land.

Whereas I'm familiar with this code but not with the opaque-pointers effort, so 
I had to look up the //other// half of what was going on :-)

If I've understood this correctly, the point is that we should no longer be 
looking inside a pointer-typed `llvm::Value` to find out its pointee type, 
because at some point in the future it will stop storing one at all? And 
therefore the codegen layer above, if it wants to know the pointee type for a 
`Value` it's already made, has to take responsibility for remembering it itself 
from the point where the `Value` was constructed.

This seems fine to me, and the uses of `address` in the actual `arm_mve.td` 
don't look as if they're likely to cause trouble with this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122046

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


[PATCH] D122046: [clang] Remove Address::deprecated from MveEmitter

2022-03-21 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/utils/TableGen/MveEmitter.cpp:1197
+const Type *Ty = nullptr;
+if (auto *DI = dyn_cast(D->getArg(0))->getOperator())
+  if (auto *PTy = dyn_cast(getType(DI, Param)))

dblaikie wrote:
> nikic wrote:
> > Should be either `cast` or check for nullptr before dereferencing?
> Not sure I follow the question - which variable are you pointing to that 
> needs a null check before its use?
Oh yes, good point, I see it. `dyn_cast(D->getArg(0))` might return 
nullptr, because the point of `dyn_cast` is that the thing you're casting might 
not have the right type. So you should check the return from `dyn_cast` before 
you dereference it to call its `getOperator` method.

(Alternatively, as @nikic hints, if you think that in this case the cast 
//cannot// fail, then you can change it to a straight `cast` which doesn't do 
the runtime check.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122046

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


[PATCH] D119720: [ARM] Pass for Cortex-A57 and Cortex-A72 Fused AES Erratum

2022-04-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: llvm/lib/Target/ARM/ARMFixCortexA57AES1742098Pass.cpp:12-19
+// The intention is this:
+// - Any 128-bit or 64-bit writes to the neon input register of an AES fused
+//   pair are safe (the inputs are to the AESE/AESD instruction).
+// - Any 32-bit writes to the input register are unsafe, but these may happen
+//   in another function, or only on some control flow paths. In these cases,
+//   conservatively insert the VORRq anyway.
+// - So, analyse both inputs to the AESE/AESD instruction, inserting a VORR if

This description would leave me still confused if I didn't happen to already 
know roughly what the plan was. It jumps in half way through the explanation 
that someone would need if they were coming to this pass cold. (E.g. it talks 
about "the VORRq" before having even mentioned //that// there is one, let alone 
//why// there is one.)

How about the suggested text as a rewording?



Comment at: llvm/lib/Target/ARM/ARMFixCortexA57AES1742098Pass.cpp:310
+
+// If there are no unsafe unsafe definitions...
+if (UnsafeCount == 0) {

nit: repeated word


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119720

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


[PATCH] D119199: replace clang LLVM_ENABLE_PLUGINS -> CLANG_PLUGIN_SUPPORT in tests

2022-02-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Hi. This commit seems to have broken the following cmake command, on Windows 
(with HEAD pointing at 76cad51ba700233d6e3492eddcbb466b6adbc2eb 
):

  cmake -DLLVM_ENABLE_PROJECTS=clang -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON 
..\llvm-project\llvm

The symptom is the same as @cristian.adam shows above:

  -- SampleAnalyzerPlugin ignored -- Loadable modules not supported on this 
platform.
  CMake Error at [...]/llvm-project/clang/cmake/modules/AddClang.cmake:185 
(target_link_libraries):
Utility target "SampleAnalyzerPlugin" must not be used as the target of a
target_link_libraries call.
  Call Stack (most recent call first):

[...]/llvm-project/clang/lib/Analysis/plugins/SampleAnalyzer/CMakeLists.txt:8 
(clang_target_link_libraries)

With HEAD pointing at the previous commit, 
`clang/lib/Analysis/plugins/CMakeLists.txt` does not add the `SampleAnalyzer` 
subdirectory at all, because `LLVM_ENABLE_PLUGINS` has the value `OFF`. But 
`CLANG_PLUGIN_SUPPORT` is `ON`, so now it does, and the above error happens.

If I try to work around this by setting `CLANG_PLUGIN_SUPPORT` to `OFF` as well 
...

  cmake -DLLVM_ENABLE_PROJECTS=clang -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON 
-DCLANG_PLUGIN_SUPPORT=OFF ..\llvm-project\llvm

... then this error happens instead:

  CMake Error at cmake/modules/AddLLVM.cmake:676 (target_link_libraries):
Target "clang" of type EXECUTABLE may not be linked into another target.
One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, or to
executables with the ENABLE_EXPORTS property set.
  Call Stack (most recent call first):
cmake/modules/AddLLVM.cmake:808 (llvm_add_library)
[...]/llvm-project/clang/examples/PrintFunctionNames/CMakeLists.txt:12 
(add_llvm_library)

So, either way, the build fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119199

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


[PATCH] D119199: replace clang LLVM_ENABLE_PLUGINS -> CLANG_PLUGIN_SUPPORT in tests

2022-02-11 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added inline comments.



Comment at: clang/tools/driver/CMakeLists.txt:53
 # Support plugins.
 if(CLANG_PLUGIN_SUPPORT)
   export_executable_symbols_for_plugins(clang)

I think we've managed to fix our build by changing this line so that it tests
```if(CLANG_PLUGIN_SUPPORT OR LLVM_EXPORT_SYMBOLS_FOR_PLUGINS)```
because that fixes the cmake complaint that you can't link against an 
executable that didn't have `ENABLE_EXPORTS`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119199

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


[PATCH] D119591: clang-analyzer plugins require LLVM_ENABLE_PLUGINS also

2022-02-14 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

I gave this patch a test against our downstream code, and found that it doesn't 
stop me needing the change I suggested in D119199 
: in `clang/tools/driver/CMakeLists.txt`, I 
had to change

  if(CLANG_PLUGIN_SUPPORT)
export_executable_symbols_for_plugins(clang)
  endif()
  ``` so that the if statement reads
  ```if(CLANG_PLUGIN_SUPPORT OR LLVM_EXPORT_SYMBOLS_FOR_PLUGINS)

because otherwise, the clang/examples builds will still try to link against the 
clang executable target, which needs its symbols to have been exported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119591

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


[PATCH] D119591: clang-analyzer plugins require LLVM_ENABLE_PLUGINS also

2022-02-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

I ran another test of this patch, by trying the cross product of the following 
cmake configuration choices (on a build targeting Windows, with 
`LLVM_ENABLE_PROJECTS=clang`):

- `LLVM_EXPORT_SYMBOLS_FOR_PLUGINS` set to each of `ON` and `OFF`
- `CLANG_BUILD_EXAMPLES` set to each of `ON` and `OFF`
- `CLANG_PLUGIN_SUPPORT` set to each of `ON` and `OFF`

3 of those 8 cases failed.

- export-symbols OFF, build-examples ON, plugin-support OFF
- export-symbols OFF, build-examples ON, plugin-support ON
- export-symbols ON, build-examples ON, plugin-support OFF (which is the 
configuration we're currently using downstream)

In all three cases, I saw errors such as this (suggesting that a plugin is 
being added to the list of things to test even though it wasn't built):

  CMake Error at cmake/modules/AddLLVM.cmake:1821 (add_dependencies):
The dependency target "AnnotateFunctions" of target "check-all" does not
exist.
  Call Stack (most recent call first):
CMakeLists.txt:1134 (add_lit_target)

Perhaps not all of the 8 configurations in this cross product are actually 
sensible? But if one of them is not sensible, it would be better to get a clear 
error message saying why, than to have to debug things like the above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119591

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


[PATCH] D119591: clang-analyzer plugins require LLVM_ENABLE_PLUGINS also

2022-02-16 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham accepted this revision.
simon_tatham added a comment.
This revision is now accepted and ready to land.

LGTM this time. Thanks very much for the rework!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119591

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


[PATCH] D12669: [libcxxabi] Fix alignment of pointers returned by fallback_malloc

2022-07-15 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

I don't know if "silence implies no objection" is a reasonable assumption in 
this community, so for the sake of not treading on toes, I've put my revised 
version of the patch in a new location instead: D129842 
.


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

https://reviews.llvm.org/D12669

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


[PATCH] D119720: [ARM] Pass for Cortex-A57 and Cortex-A72 Fused AES Erratum

2022-05-13 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham accepted this revision.
simon_tatham added a comment.

Thanks, that explanation looks fine. (And I agree that re-paragraphing it made 
more sense than my version)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119720

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


[PATCH] D67159: [clang] New __attribute__((__clang_builtin)).

2019-09-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, miyuki, ostannard.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This allows you to declare a function with a name of your choice (say
`foo`), but have clang treat it as if it were a builtin function (say
`__builtin_foo`), by writing

  static __inline__ __attribute__((__clang_builtin(__builtin_foo)))
  int foo(args);

I'm intending to use this for the ACLE intrinsics for MVE, which have
to be polymorphic on their argument types and also implemented by
builtins. This commit itself just introduces the new attribute, and
doesn't use it for anything.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67159

Files:
  clang/include/clang/Basic/Attr.td
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test


Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -36,6 +36,7 @@
 // CHECK-NEXT: Callback (SubjectMatchRule_function)
 // CHECK-NEXT: Capability (SubjectMatchRule_record, 
SubjectMatchRule_type_alias)
 // CHECK-NEXT: CarriesDependency (SubjectMatchRule_variable_is_parameter, 
SubjectMatchRule_objc_method, SubjectMatchRule_function)
+// CHECK-NEXT: ClangBuiltinOverride (SubjectMatchRule_function)
 // CHECK-NEXT: Cold (SubjectMatchRule_function)
 // CHECK-NEXT: Common (SubjectMatchRule_variable)
 // CHECK-NEXT: Constructor (SubjectMatchRule_function)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -5041,6 +5041,13 @@
   AL.getAttributeSpellingListIndex()));
 }
 
+static void handleClangBuiltinOverrideAttribute(Sema &S, Decl *D,
+const ParsedAttr &AL) {
+  D->addAttr(::new (S.Context) ClangBuiltinOverrideAttr(
+  AL.getRange(), S.Context, AL.getArgAsIdent(0)->Ident,
+  AL.getAttributeSpellingListIndex()));
+}
+
 
//===--===//
 // Checker-specific attribute handlers.
 
//===--===//
@@ -7430,6 +7437,10 @@
   case ParsedAttr::AT_MSAllocator:
 handleMSAllocatorAttr(S, D, AL);
 break;
+
+  case ParsedAttr::AT_ClangBuiltinOverride:
+handleClangBuiltinOverrideAttribute(S, D, AL);
+break;
   }
 }
 
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -3075,10 +3075,18 @@
 /// functions as their wrapped builtins. This shouldn't be done in general, but
 /// it's useful in Sema to diagnose calls to wrappers based on their semantics.
 unsigned FunctionDecl::getBuiltinID(bool ConsiderWrapperFunctions) const {
-  if (!getIdentifier())
-return 0;
+  unsigned BuiltinID;
+
+  if (hasAttr()) {
+IdentifierInfo *II = getAttr()->getBuiltinName();
+BuiltinID = II->getBuiltinID();
+  } else {
+if (!getIdentifier())
+  return 0;
+
+BuiltinID = getIdentifier()->getBuiltinID();
+  }
 
-  unsigned BuiltinID = getIdentifier()->getBuiltinID();
   if (!BuiltinID)
 return 0;
 
@@ -3102,7 +3110,8 @@
 
   // If the function is marked "overloadable", it has a different mangled name
   // and is not the C library function.
-  if (!ConsiderWrapperFunctions && hasAttr())
+  if (!ConsiderWrapperFunctions && hasAttr() &&
+  !hasAttr())
 return 0;
 
   if (!Context.BuiltinInfo.isPredefinedLibFunction(BuiltinID))
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -593,6 +593,12 @@
   let Subjects = SubjectList<[Function, GlobalVar], ErrorDiag>;
   let Documentation = [Undocumented];
 }
+def ClangBuiltinOverride : Attr {
+  let Spellings = [GCC<"__clang_builtin">];
+  let Args = [IdentifierArgument<"BuiltinName">];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [Undocumented];
+}
 
 def Aligned : InheritableAttr {
   let Spellings = [GCC<"aligned">, Declspec<"align">, Keyword<"alignas">,


Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -36,6 +36,7 @@
 // CHECK-NEXT: Callback (SubjectMatchRule_function)
 // CHECK-NEXT: Capability (SubjectMatchRule_record, SubjectMatchRule_type_alias)
 // CHECK-NEXT: CarriesDependency (SubjectMatchRule_variable_is_parameter, SubjectMatchRule_objc_me

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

2019-09-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, miyuki, ostannard.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

The ACLE intrinsics for the MVE instruction set have polymorphic
variants: you can write vaddq(v,w) and have it automatically select
vaddq_s32, vaddq_u8, vaddq_f16, ... according to the types of the
vector variables v and w.

In order to implement this using __attribute__((overloadable)), I need
to turn on strict type-checking between the different vector types, or
else clang will believe that any vector type matches _all_ of those
function prototypes, and won't be able to select the right one.

Also, I think this makes sense for MVE anyway, on error-checking
grounds. For NEON, where every intrinsic in C source explicitly
describes the operation it's performing, you could argue that the
distinct vector types aren't essential; but in a context where getting
the wrong type can cause silent generation of the _wrong_ code, I
think it's better to warn users as soon as possible if they've written
code that isn't using vector types consistently.

So this commit introduces a (minimal) piece of infrastructure to allow
the default for OPT_flax_vector_conversions to vary based on the
target triple, and uses it to set the default specially for
ARMSubArch_v8_1m_mainline (in which the only possible vector
architecture will be MVE).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67160

Files:
  clang/lib/Driver/ToolChains/Clang.cpp


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1357,6 +1357,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4674,10 +4685,13 @@
   if (TC.SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_mfentry);
 
-  // -flax-vector-conversions is default.
-  if (!Args.hasFlag(options::OPT_flax_vector_conversions,
-options::OPT_fno_lax_vector_conversions))
+  if (const Arg *A = Args.getLastArg(options::OPT_flax_vector_conversions,
+options::OPT_fno_lax_vector_conversions)) {
+if (A->getOption().matches(options::OPT_fno_lax_vector_conversions))
+  CmdArgs.push_back("-fno-lax-vector-conversions");
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
 CmdArgs.push_back("-fno-lax-vector-conversions");
+  }
 
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1357,6 +1357,17 @@
   }
 }
 
+static bool isLaxVectorConversionsDefault(const llvm::Triple &Triple) {
+  switch (Triple.getArch()) {
+  default:
+return true;
+
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+return Triple.getSubArch() != llvm::Triple::ARMSubArch_v8_1m_mainline;
+  }
+}
+
 static bool isNoCommonDefault(const llvm::Triple &Triple) {
   switch (Triple.getArch()) {
   default:
@@ -4674,10 +4685,13 @@
   if (TC.SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_mfentry);
 
-  // -flax-vector-conversions is default.
-  if (!Args.hasFlag(options::OPT_flax_vector_conversions,
-options::OPT_fno_lax_vector_conversions))
+  if (const Arg *A = Args.getLastArg(options::OPT_flax_vector_conversions,
+options::OPT_fno_lax_vector_conversions)) {
+if (A->getOption().matches(options::OPT_fno_lax_vector_conversions))
+  CmdArgs.push_back("-fno-lax-vector-conversions");
+  } else if (!isLaxVectorConversionsDefault(Triple)) {
 CmdArgs.push_back("-fno-lax-vector-conversions");
+  }
 
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D67159: [clang] New __attribute__((__clang_builtin)).

2019-09-04 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

Sorry about that – I didn't want to put the discussion of rationale in too many 
different places. The commit message for the followup patch D67161 
 discusses it a bit.

The usual thing in previous intrinsics systems like NEON is that you have a 
wrapper function in the header file which calls the builtin. That already 
doesn't work in every situation, because some intrinsics need one of their 
arguments to be a compile-time integer constant expression, and with a wrapper 
function in the way, the constantness property is lost between the user's call 
site and the builtin. So then you implement //those// builtins as macros 
instead of wrapper functions.

The MVE intrinsics spec adds the wrinkle that there are polymorphic functions – 
with more concise names, overloaded on the argument types. For example, 
`vaddq(v,w)` can behave like `vaddq_s32` or `vaddq_f16` or whatever, depending 
on what vector types you give it. Those have to be implemented using either 
`__attribute__((overloadable))` or `_Generic`.

`__attribute__((overloadable))` works fine for wrapper functions in the header 
file, but not for that awkward subset of the functions that have to fall back 
to being macros. For those, you //have// to use `_Generic` (if you're not 
willing to do what I've done here).

`_Generic` is immensely awkward, because the difficult thing about it is that 
all the selection branches //not// taken still have to type-check successfully. 
So you can't just say something like 'if this is a `uint16x8_t` then expand to 
`vfooq_u16`, else `vfooq_f16`, etc', because all but one of those will be type 
errors. Instead you have to pile in endless workarounds in which each branch of 
the `_Generic` is filled with sub-Generics that coerce the arguments in untaken 
branches to something that is nonsense but won't cause a type-check error – and 
//hope// that none of your 'replace it with validly typed nonsense' workarounds 
won't accidentally trigger in any case where the branch //is// taken.

Also, if you need to disambiguate based on //more// than one of the argument 
types (which can happen in this spec), then you have the same problem again: 
you can't nest a `_Generic` switching on argument 2 inside each branch of an 
outer one switching on argument 1, because as soon as the set of legal type 
pairs isn't a full Cartesian product, the inner Generic of an untaken branch 
fails to type-check again, so you need yet more layers of workaround.

And after you've done all that, the error reporting is //hideous//. It's almost 
as bad as those C++ error messages gcc used to generate in which it had 
expanded out some STL type in the user's code into three whole pages of 
library-internals nonsense.

Doing it //this// way, what happens is that first clang resolves the 
`__attribute__((overloadable))` based on all the argument types at once; then, 
once it's decided which function declaration is the interesting one, it looks 
up the `BuiltinId` that I put there using this mechanism; and then it's looking 
at a call directly to that builtin from the user's code, so it can check 
constant arguments at their original call site. It needs almost no code; no 
enormous chain of ugly workarounds; and if the user passes an invalid list of 
argument types, the error report is //beautiful//: clang will show you each 
declaration of the polymorphic name from the header file, and legibly explain 
why each one doesn't match the arguments the user actually passed.

So, I hear you: this is something clang has always found a way to do without 
before. But if I can't do it this way, could you suggest a way that I could get 
anything like that really nice error reporting, under all those constraints at 
once?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


[PATCH] D67159: [clang] New __attribute__((__clang_builtin)).

2019-09-05 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked 2 inline comments as done.
simon_tatham added a comment.

On the general discomfort with this attribute existing: I'd be happy to lock it 
down, or mark it as "not recommended" in some way, if that's any help. I don't 
personally intend any use of it outside a single system header file (namely 
`arm_mve.h`, which D67161  will introduce the 
initial version of).

A warning along the lines of "don't use this!", automatically suppressed by the 
usual change of warning settings in system headers, would seem like a perfectly 
reasonable precaution, for example.




Comment at: clang/include/clang/Basic/Attr.td:596
 }
+def ClangBuiltinOverride : Attr {
+  let Spellings = [GCC<"__clang_builtin">];

aaron.ballman wrote:
> Do you expect this attribute to be inherited on redeclarations? I suspect 
> this should be an `InheritableAttr`.
> 
> Also, add a newline above it for visual separation, please.
> 
> Finally, should this be a target-specific attribute so that it's only 
> available for your target, or do you expect this attribute to be used on all 
> target architectures?
For my use case, I have no opinion about redeclarations: I expect to declare 
each affected function exactly once. If you think `InheritableAttr` is a more 
sensible default choice, I'm fine with that.

Target-specific: I don't have a use case outside the ARM target, so I'd be 
happy to lock it down that way if you want.



Comment at: clang/include/clang/Basic/Attr.td:600
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [Undocumented];
+}

aaron.ballman wrote:
> No new undocumented attributes, please.
OK. I'd intended to leave it undocumented in order to discourage people from 
using it in any context //other// than a system header file. But fair enough – 
perhaps it should be documented even so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67159



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


  1   2   3   4   >