[PATCH] D50068: [AArch64][ARM] Add Armv8.4-A tests

[Ahmed Bougacha via Phabricator via cfe-commits]

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

LGTM, thanks!




Comment at: test/Driver/aarch64-cpus.c:9
 // RUN: %clang -target aarch64_be -mlittle-endian -mcpu=generic -### -c %s 
2>&1 | FileCheck -check-prefix=GENERIC %s
 // GENERIC: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "generic"
 

Ideally, these should test `aarch64-{{.*}}`, no?


https://reviews.llvm.org/D50068



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

[PATCH] D58320: [Darwin] Introduce a new flag, -fapple-link-rtlib that forces linking of the builtins library.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

Please check the embedded thing (the other comments are minor).  Otherwise, 
LGTM; if you have found this flag to be necessary, this looks like a reasonable 
way to implement it




Comment at: clang/include/clang/Driver/Options.td:1252
+def fapple_link_rtlib : Flag<["-"], "fapple-link-rtlib">, Group,
+  HelpText<"Apple specific option to force linking the clang builtins runtime 
library">;
 def flto_EQ : Joined<["-"], "flto=">, Flags<[CoreOption, CC1Option]>, 
Group,

Hmm, maybe move "Apple specific" to a parenthesis at the end?

Also, I'm guessing this belonged here when it was "-flink-rtlib", it doesn't 
anymore.



Comment at: clang/lib/Driver/ToolChains/Darwin.cpp:573
+  bool NoStdOrDefaultLibs =
+  Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs);
+  bool ForceLinkBuiltins = Args.hasArg(options::OPT_fapple_link_rtlib);

Maybe sink this to the AddLinkRuntimeLibArgs implementations (as an extra 
parameter or directly checking the args)?  The flags don't bypass the whole 
thing anymore, might as well treat it like -mkernel and whatnot.



Comment at: clang/lib/Driver/ToolChains/Darwin.cpp:2084
 
   AddLinkRuntimeLib(Args, CmdArgs, CompilerRT, RLO_IsEmbedded);
 }

This is different from 'builtins'.  Are you OK with the difference?  Otherwise 
maybe this should be an error for now;  I wouldn't be surprised if we never hit 
this path (this part, I'm not familiar with)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58320



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

[PATCH] D53633: [AArch64] Implement FP16FML intrinsics

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.
Herald added a subscriber: jdoerfert.
Herald added a project: LLVM.



Comment at: cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c:12
+
+float32x2_t test_vfmlal_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_low_u32(<2 x float> %a, <4 x 
half> %b, <4 x half> %c)

Hey folks, I'm curious: where does the "_u32" suffix come from? Should it be 
_f16?

Also, are there any new ACLE/intrinsic list documents? As far as I can tell 
there hasn't been any release since IHI0073B/IHI0053D.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53633



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

[PATCH] D58306: [AArch64] Change size suffix for FP16FML intrinsics.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
ab added reviewers: SjoerdMeijer, bryanpkc.
ab added a project: clang.
Herald added a subscriber: javed.absar.

These currently use _u32, but they should instead use _f32 or _f16, the types 
of the accumulator, and of the multiplication.

I'm starting with _f16 (because that seems to match the various integer vmlal 
variants), but either seems fine.


Repository:
  rC Clang

https://reviews.llvm.org/D58306

Files:
  include/clang/Basic/arm_neon.td
  test/CodeGen/aarch64-neon-fp16fml.c

Index: test/CodeGen/aarch64-neon-fp16fml.c
===
--- test/CodeGen/aarch64-neon-fp16fml.c
+++ test/CodeGen/aarch64-neon-fp16fml.c
@@ -9,188 +9,188 @@
 
 // Vector form
 
-float32x2_t test_vfmlal_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_low_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_low_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlal.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlal_low_u32(a, b, c);
+  return vfmlal_low_f16(a, b, c);
 }
 
-float32x2_t test_vfmlsl_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlsl_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlsl.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlsl_low_u32(a, b, c);
+  return vfmlsl_low_f16(a, b, c);
 }
 
-float32x2_t test_vfmlal_high_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_high_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_high_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_high_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlal2.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlal_high_u32(a, b, c);
+  return vfmlal_high_f16(a, b, c);
 }
 
-float32x2_t test_vfmlsl_high_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlsl_high_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlsl_high_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlsl_high_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlsl2.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlsl_high_u32(a, b, c);
+  return vfmlsl_high_f16(a, b, c);
 }
 
-float32x4_t test_vfmlalq_low_u32(float32x4_t a, float16x8_t b, float16x8_t c) {
-// CHECK-LABEL: define <4 x float> @test_vfmlalq_low_u32(<4 x float> %a, <8 x half> %b, <8 x half> %c)
+float32x4_t test_vfmlalq_low_f16(float32x4_t a, float16x8_t b, float16x8_t c) {
+// CHECK-LABEL: define <4 x float> @test_vfmlalq_low_f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <4 x float> @llvm.aarch64.neon.fmlal.v4f32.v8f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: ret <4 x float> [[RESULT]]
-  return vfmlalq_low_u32(a, b, c);
+  return vfmlalq_low_f16(a, b, c);
 }
 
-float32x4_t test_vfmlslq_low_u32(float32x4_t a, float16x8_t b, float16x8_t c) {
-// CHECK-LABEL: define <4 x float> @test_vfmlslq_low_u32(<4 x float> %a, <8 x half> %b, <8 x half> %c)
+float32x4_t test_vfmlslq_low_f16(float32x4_t a, float16x8_t b, float16x8_t c) {
+// CHECK-LABEL: define <4 x float> @test_vfmlslq_low_f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <4 x float> @llvm.aarch64.neon.fmlsl.v4f32.v8f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: ret <4 x float> [[RESULT]]
-  return vfmlslq_low_u32(a, b, c);
+  return vfmlslq_low_f16(a, b, c);
 }
 
-float32x4_t test_vfmlalq_high_u32(float32x4_t a, float16x8_t b, float16x8_t c) {
-// CHECK-LABEL: define <4 x float> @test_vfmlalq_high_u32(<4 x float> %a, <8 x half> %b, <8 x half> %c)
+float32x4_t test_vfmlalq_high_f16(float32x4_t a, float16x8_t b, float16x8_t c) {
+// CHECK-LABEL: define <4 x float> @test_vfmlalq_high_f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <4 x float> @llvm.aarch64.neon.fmlal2.v4f32.v8f16(<4 x float> %a, <8 x half> %b, <8 x half> %c)
 // CHECK: ret <4 x float> [[RESULT]]
-  return vfmlalq_high_u32(a, b, c);
+  re

[PATCH] D53633: [AArch64] Implement FP16FML intrinsics

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c:12
+
+float32x2_t test_vfmlal_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_low_u32(<2 x float> %a, <4 x 
half> %b, <4 x half> %c)

SjoerdMeijer wrote:
> SjoerdMeijer wrote:
> > ab wrote:
> > > Hey folks, I'm curious: where does the "_u32" suffix come from? Should it 
> > > be _f16?
> > > 
> > > Also, are there any new ACLE/intrinsic list documents? As far as I can 
> > > tell there hasn't been any release since IHI0073B/IHI0053D.
> > > Also, are there any new ACLE/intrinsic list documents? As far as I can 
> > > tell there hasn't been any release since IHI0073B/IHI0053D.
> > 
> > I've checked, and an updated ACLE that includes these FP16FML intrinsics is 
> > coming soon.
> > 
> > > where does the "_u32" suffix come from? Should it be _f16?
> > 
> > Good question. It could probably be _f32 or _f16, but _u32 doesn't seem to 
> > make much sense. Looks like the spec says _u32, and that's also what GCC 
> > has implemented. I think we want to update the spec and fix the name before 
> > the updated spec is available. Will chase this, and let you know once I 
> > know more.
> An update on this: we should change this to _f32 (because the first suffixes 
> were refering to the ouput type). The ACLE will be updated accordingly, and 
> also GCC will change its current implementation (from _u32 to _f32).  Many 
> thanks for raising this issue.
> Is there a volunteer to prepare a patch? Or do you have one already? :-) I 
> could look at it, but that will be towards the end of next week.
> I've checked, and an updated ACLE that includes these FP16FML intrinsics is 
> coming soon.

Great, thanks!

> An update on this: we should change this to _f32 (because the first suffixes 
> were refering to the ouput type).

Hmm, I was thinking _f16 based on the vmlal intrinsics: they seem to be named 
after the multiplication type rather than that of the accumulator/output.

Either way seems fine to me though, I'll defer to you folks.

> The ACLE will be updated accordingly, and also GCC will change its current 
> implementation (from _u32 to _f32). Many thanks for raising this issue.
Is there a volunteer to prepare a patch? Or do you have one already? :-) I 
could look at it, but that will be towards the end of next week.

Sure: D58306 (with _f16 though, let me know what you think of vmlal)

Thanks for checking!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53633



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

[PATCH] D58306: [AArch64] Change size suffix for FP16FML intrinsics.

[Ahmed Bougacha via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL354538: [AArch64] Change size suffix for FP16FML intrinsics. 
(authored by ab, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58306?vs=187083&id=187696#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D58306

Files:
  cfe/trunk/include/clang/Basic/arm_neon.td
  cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c

Index: cfe/trunk/include/clang/Basic/arm_neon.td
===
--- cfe/trunk/include/clang/Basic/arm_neon.td
+++ cfe/trunk/include/clang/Basic/arm_neon.td
@@ -1651,18 +1651,18 @@
 
 // v8.2-A FP16 fused multiply-add long instructions.
 let ArchGuard = "defined(__ARM_FEATURE_FP16FML) && defined(__aarch64__)" in {
-  def VFMLAL_LOW  : SInst<"vfmlal_low", "ffHH", "UiQUi">;
-  def VFMLSL_LOW  : SInst<"vfmlsl_low", "ffHH", "UiQUi">;
-  def VFMLAL_HIGH : SInst<"vfmlal_high", "ffHH", "UiQUi">;
-  def VFMLSL_HIGH : SInst<"vfmlsl_high", "ffHH", "UiQUi">;
-
-  def VFMLAL_LANE_LOW  : SOpInst<"vfmlal_lane_low", "ffH0i", "UiQUi", OP_FMLAL_LN>;
-  def VFMLSL_LANE_LOW  : SOpInst<"vfmlsl_lane_low", "ffH0i", "UiQUi", OP_FMLSL_LN>;
-  def VFMLAL_LANE_HIGH : SOpInst<"vfmlal_lane_high", "ffH0i", "UiQUi", OP_FMLAL_LN_Hi>;
-  def VFMLSL_LANE_HIGH : SOpInst<"vfmlsl_lane_high", "ffH0i", "UiQUi", OP_FMLSL_LN_Hi>;
-
-  def VFMLAL_LANEQ_LOW  : SOpInst<"vfmlal_laneq_low", "ffH1i", "UiQUi", OP_FMLAL_LN>;
-  def VFMLSL_LANEQ_LOW  : SOpInst<"vfmlsl_laneq_low", "ffH1i", "UiQUi", OP_FMLSL_LN>;
-  def VFMLAL_LANEQ_HIGH : SOpInst<"vfmlal_laneq_high", "ffH1i", "UiQUi", OP_FMLAL_LN_Hi>;
-  def VFMLSL_LANEQ_HIGH : SOpInst<"vfmlsl_laneq_high", "ffH1i", "UiQUi", OP_FMLSL_LN_Hi>;
+  def VFMLAL_LOW  : SInst<"vfmlal_low",  "ffHH", "hQh">;
+  def VFMLSL_LOW  : SInst<"vfmlsl_low",  "ffHH", "hQh">;
+  def VFMLAL_HIGH : SInst<"vfmlal_high", "ffHH", "hQh">;
+  def VFMLSL_HIGH : SInst<"vfmlsl_high", "ffHH", "hQh">;
+
+  def VFMLAL_LANE_LOW  : SOpInst<"vfmlal_lane_low",  "ffH0i", "hQh", OP_FMLAL_LN>;
+  def VFMLSL_LANE_LOW  : SOpInst<"vfmlsl_lane_low",  "ffH0i", "hQh", OP_FMLSL_LN>;
+  def VFMLAL_LANE_HIGH : SOpInst<"vfmlal_lane_high", "ffH0i", "hQh", OP_FMLAL_LN_Hi>;
+  def VFMLSL_LANE_HIGH : SOpInst<"vfmlsl_lane_high", "ffH0i", "hQh", OP_FMLSL_LN_Hi>;
+
+  def VFMLAL_LANEQ_LOW  : SOpInst<"vfmlal_laneq_low",  "ffH1i", "hQh", OP_FMLAL_LN>;
+  def VFMLSL_LANEQ_LOW  : SOpInst<"vfmlsl_laneq_low",  "ffH1i", "hQh", OP_FMLSL_LN>;
+  def VFMLAL_LANEQ_HIGH : SOpInst<"vfmlal_laneq_high", "ffH1i", "hQh", OP_FMLAL_LN_Hi>;
+  def VFMLSL_LANEQ_HIGH : SOpInst<"vfmlsl_laneq_high", "ffH1i", "hQh", OP_FMLSL_LN_Hi>;
 }
Index: cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c
===
--- cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c
+++ cfe/trunk/test/CodeGen/aarch64-neon-fp16fml.c
@@ -9,188 +9,188 @@
 
 // Vector form
 
-float32x2_t test_vfmlal_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_low_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_low_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlal.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlal_low_u32(a, b, c);
+  return vfmlal_low_f16(a, b, c);
 }
 
-float32x2_t test_vfmlsl_low_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlsl_low_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlsl_low_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlsl.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlsl_low_u32(a, b, c);
+  return vfmlsl_low_f16(a, b, c);
 }
 
-float32x2_t test_vfmlal_high_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: define <2 x float> @test_vfmlal_high_u32(<2 x float> %a, <4 x half> %b, <4 x half> %c)
+float32x2_t test_vfmlal_high_f16(float32x2_t a, float16x4_t b, float16x4_t c) {
+// CHECK-LABEL: define <2 x float> @test_vfmlal_high_f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: [[RESULT:%.*]] = call <2 x float> @llvm.aarch64.neon.fmlal2.v2f32.v4f16(<2 x float> %a, <4 x half> %b, <4 x half> %c)
 // CHECK: ret <2 x float> [[RESULT]]
-  return vfmlal_high_u32(a, b, c);
+  return vfmlal_high_f16(a, b, c);
 }
 
-float32x2_t test_vfmlsl_high_u32(float32x2_t a, float16x4_t b, float16x4_t c) {
-// CHECK-LABEL: d

[PATCH] D58306: [AArch64] Change size suffix for FP16FML intrinsics.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

Thanks for checking, much appreciated!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58306



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

[PATCH] D55731: [darwin][arm64] use the "cyclone" CPU for Darwin even when `-arch` is not specified

[Ahmed Bougacha via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D55731



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

[PATCH] D46042: Cap vector alignment at 16 for all Darwin platforms

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

So, this makes sense to me, but on x86, should we also be worried about the 
fact that the calling convention is based on which features are available?  
(>128bit ext_vector_types are passed in AVX/AVX-512 registers, if available).  
Presumably swift is also affected, no?


Repository:
  rC Clang

https://reviews.llvm.org/D46042



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

[PATCH] D48700: [CMake] Make bootstrap and compiler-rt depend on cxx-headers.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
ab added a reviewer: phosek.
Herald added subscribers: mgorny, dberris.

Since r334468, my understanding is, we no longer always copy the libcxx headers 
by virtue of their presence when cmake runs.

This is an attempt to make some of the later stages (compiler-rt, and the 
bootstrapped stages) depend on them being copied, via the cxx-headers target.


Repository:
  rC Clang

https://reviews.llvm.org/D48700

Files:
  CMakeLists.txt
  runtime/CMakeLists.txt


Index: runtime/CMakeLists.txt
===
--- runtime/CMakeLists.txt
+++ runtime/CMakeLists.txt
@@ -58,8 +58,12 @@
 endif()
   endforeach()
 
+  if(TARGET cxx-headers)
+set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+  endif()
+
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang
+DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -621,10 +621,15 @@
 LLVM_ENABLE_PROJECTS
 LLVM_ENABLE_RUNTIMES)
 
-  # We don't need to depend on compiler-rt if we're building instrumented
+  # We don't need to depend on compiler-rt/libcxx if we're building 
instrumented
   # because the next stage will use the same compiler used to build this stage.
-  if(TARGET compiler-rt AND NOT LLVM_BUILD_INSTRUMENTED)
-add_dependencies(clang-bootstrap-deps compiler-rt)
+  if(NOT LLVM_BUILD_INSTRUMENTED)
+if(TARGET compiler-rt)
+  add_dependencies(clang-bootstrap-deps compiler-rt)
+endif()
+if(TARGET cxx-headers)
+  add_dependencies(clang-bootstrap-deps cxx-headers)
+endif()
   endif()
 
   set(C_COMPILER "clang")


Index: runtime/CMakeLists.txt
===
--- runtime/CMakeLists.txt
+++ runtime/CMakeLists.txt
@@ -58,8 +58,12 @@
 endif()
   endforeach()
 
+  if(TARGET cxx-headers)
+set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+  endif()
+
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang
+DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -621,10 +621,15 @@
 LLVM_ENABLE_PROJECTS
 LLVM_ENABLE_RUNTIMES)
 
-  # We don't need to depend on compiler-rt if we're building instrumented
+  # We don't need to depend on compiler-rt/libcxx if we're building instrumented
   # because the next stage will use the same compiler used to build this stage.
-  if(TARGET compiler-rt AND NOT LLVM_BUILD_INSTRUMENTED)
-add_dependencies(clang-bootstrap-deps compiler-rt)
+  if(NOT LLVM_BUILD_INSTRUMENTED)
+if(TARGET compiler-rt)
+  add_dependencies(clang-bootstrap-deps compiler-rt)
+endif()
+if(TARGET cxx-headers)
+  add_dependencies(clang-bootstrap-deps cxx-headers)
+endif()
   endif()
 
   set(C_COMPILER "clang")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48701: [CMake] Rename cxx_headers back to cxx-headers.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
ab added a reviewer: phosek.
Herald added subscribers: ldionne, mgorny.

r334477 renamed the cxx-headers target to cxx_headers, but various pieces 
sort-of expect the target names to match the component (e.g., 
LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via some 
magic foreign to me, seems to expect cxx-headers, install-cxx-headers, and 
install-cxx-headers-stripped to exist)

We're still finding places that need to be changed, so, unless there was a 
reason for that change, revert back to cxx-headers (which, anecdotally, matches 
"clang-headers" for the clang lib/Headers/)

Otherwise, perhaps we should have target "aliases" (it seems like that's the 
reason why there are both *libcxx-headers* and *cxx-headers* variants of a few 
targets)


Repository:
  rCXX libc++

https://reviews.llvm.org/D48701

Files:
  include/CMakeLists.txt
  lib/CMakeLists.txt


Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -286,7 +286,7 @@
 endif()
 
 # Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
+add_custom_target(cxx DEPENDS cxx-headers ${LIBCXX_TARGETS})
 
 if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
   file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
Index: include/CMakeLists.txt
===
--- include/CMakeLists.txt
+++ include/CMakeLists.txt
@@ -228,11 +228,11 @@
 list(APPEND out_files ${dst})
   endif()
 
-  add_custom_target(cxx_headers ALL DEPENDS ${out_files} 
${LIBCXX_CXX_ABI_HEADER_TARGET})
+  add_custom_target(cxx-headers ALL DEPENDS ${out_files} 
${LIBCXX_CXX_ABI_HEADER_TARGET})
 else()
-  add_custom_target(cxx_headers)
+  add_custom_target(cxx-headers)
 endif()
-set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
+set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
@@ -255,7 +255,7 @@
 
   if (NOT CMAKE_CONFIGURATION_TYPES)
 add_custom_target(install-cxx-headers
-  DEPENDS cxx_headers ${generated_config_deps}
+  DEPENDS cxx-headers ${generated_config_deps}
   COMMAND "${CMAKE_COMMAND}"
   -DCMAKE_INSTALL_COMPONENT=cxx-headers
   -P "${CMAKE_BINARY_DIR}/cmake_install.cmake")


Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -286,7 +286,7 @@
 endif()
 
 # Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
+add_custom_target(cxx DEPENDS cxx-headers ${LIBCXX_TARGETS})
 
 if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
   file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
Index: include/CMakeLists.txt
===
--- include/CMakeLists.txt
+++ include/CMakeLists.txt
@@ -228,11 +228,11 @@
 list(APPEND out_files ${dst})
   endif()
 
-  add_custom_target(cxx_headers ALL DEPENDS ${out_files} ${LIBCXX_CXX_ABI_HEADER_TARGET})
+  add_custom_target(cxx-headers ALL DEPENDS ${out_files} ${LIBCXX_CXX_ABI_HEADER_TARGET})
 else()
-  add_custom_target(cxx_headers)
+  add_custom_target(cxx-headers)
 endif()
-set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
+set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
@@ -255,7 +255,7 @@
 
   if (NOT CMAKE_CONFIGURATION_TYPES)
 add_custom_target(install-cxx-headers
-  DEPENDS cxx_headers ${generated_config_deps}
+  DEPENDS cxx-headers ${generated_config_deps}
   COMMAND "${CMAKE_COMMAND}"
   -DCMAKE_INSTALL_COMPONENT=cxx-headers
   -P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48700: [CMake] Make bootstrap and compiler-rt depend on cxx-headers.

[Ahmed Bougacha via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL335898: [CMake] Make bootstrap and compiler-rt depend on 
cxx-headers. (authored by ab, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D48700?vs=153248&id=153362#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D48700

Files:
  cfe/trunk/CMakeLists.txt
  cfe/trunk/runtime/CMakeLists.txt


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,8 +58,12 @@
 endif()
   endforeach()
 
+  if(TARGET cxx-headers)
+set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+  endif()
+
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang
+DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -621,10 +621,15 @@
 LLVM_ENABLE_PROJECTS
 LLVM_ENABLE_RUNTIMES)
 
-  # We don't need to depend on compiler-rt if we're building instrumented
+  # We don't need to depend on compiler-rt/libcxx if we're building 
instrumented
   # because the next stage will use the same compiler used to build this stage.
-  if(TARGET compiler-rt AND NOT LLVM_BUILD_INSTRUMENTED)
-add_dependencies(clang-bootstrap-deps compiler-rt)
+  if(NOT LLVM_BUILD_INSTRUMENTED)
+if(TARGET compiler-rt)
+  add_dependencies(clang-bootstrap-deps compiler-rt)
+endif()
+if(TARGET cxx-headers)
+  add_dependencies(clang-bootstrap-deps cxx-headers)
+endif()
   endif()
 
   set(C_COMPILER "clang")


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,8 +58,12 @@
 endif()
   endforeach()
 
+  if(TARGET cxx-headers)
+set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+  endif()
+
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang
+DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -621,10 +621,15 @@
 LLVM_ENABLE_PROJECTS
 LLVM_ENABLE_RUNTIMES)
 
-  # We don't need to depend on compiler-rt if we're building instrumented
+  # We don't need to depend on compiler-rt/libcxx if we're building instrumented
   # because the next stage will use the same compiler used to build this stage.
-  if(TARGET compiler-rt AND NOT LLVM_BUILD_INSTRUMENTED)
-add_dependencies(clang-bootstrap-deps compiler-rt)
+  if(NOT LLVM_BUILD_INSTRUMENTED)
+if(TARGET compiler-rt)
+  add_dependencies(clang-bootstrap-deps compiler-rt)
+endif()
+if(TARGET cxx-headers)
+  add_dependencies(clang-bootstrap-deps cxx-headers)
+endif()
   endif()
 
   set(C_COMPILER "clang")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48701: [CMake] Rename cxx_headers back to cxx-headers.

[Ahmed Bougacha via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL335899: [CMake] Rename cxx_headers back to cxx-headers. 
(authored by ab, committed by ).
Herald added subscribers: llvm-commits, christof.

Changed prior to commit:
  https://reviews.llvm.org/D48701?vs=153251&id=153363#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D48701

Files:
  libcxx/trunk/include/CMakeLists.txt
  libcxx/trunk/lib/CMakeLists.txt


Index: libcxx/trunk/include/CMakeLists.txt
===
--- libcxx/trunk/include/CMakeLists.txt
+++ libcxx/trunk/include/CMakeLists.txt
@@ -228,11 +228,11 @@
 list(APPEND out_files ${dst})
   endif()
 
-  add_custom_target(cxx_headers ALL DEPENDS ${out_files} 
${LIBCXX_CXX_ABI_HEADER_TARGET})
+  add_custom_target(cxx-headers ALL DEPENDS ${out_files} 
${LIBCXX_CXX_ABI_HEADER_TARGET})
 else()
-  add_custom_target(cxx_headers)
+  add_custom_target(cxx-headers)
 endif()
-set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
+set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
@@ -255,7 +255,7 @@
 
   if (NOT CMAKE_CONFIGURATION_TYPES)
 add_custom_target(install-cxx-headers
-  DEPENDS cxx_headers ${generated_config_deps}
+  DEPENDS cxx-headers ${generated_config_deps}
   COMMAND "${CMAKE_COMMAND}"
   -DCMAKE_INSTALL_COMPONENT=cxx-headers
   -P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
Index: libcxx/trunk/lib/CMakeLists.txt
===
--- libcxx/trunk/lib/CMakeLists.txt
+++ libcxx/trunk/lib/CMakeLists.txt
@@ -286,7 +286,7 @@
 endif()
 
 # Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
+add_custom_target(cxx DEPENDS cxx-headers ${LIBCXX_TARGETS})
 
 if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
   file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)


Index: libcxx/trunk/include/CMakeLists.txt
===
--- libcxx/trunk/include/CMakeLists.txt
+++ libcxx/trunk/include/CMakeLists.txt
@@ -228,11 +228,11 @@
 list(APPEND out_files ${dst})
   endif()
 
-  add_custom_target(cxx_headers ALL DEPENDS ${out_files} ${LIBCXX_CXX_ABI_HEADER_TARGET})
+  add_custom_target(cxx-headers ALL DEPENDS ${out_files} ${LIBCXX_CXX_ABI_HEADER_TARGET})
 else()
-  add_custom_target(cxx_headers)
+  add_custom_target(cxx-headers)
 endif()
-set_target_properties(cxx_headers PROPERTIES FOLDER "Misc")
+set_target_properties(cxx-headers PROPERTIES FOLDER "Misc")
 
 if (LIBCXX_INSTALL_HEADERS)
   foreach(file ${files})
@@ -255,7 +255,7 @@
 
   if (NOT CMAKE_CONFIGURATION_TYPES)
 add_custom_target(install-cxx-headers
-  DEPENDS cxx_headers ${generated_config_deps}
+  DEPENDS cxx-headers ${generated_config_deps}
   COMMAND "${CMAKE_COMMAND}"
   -DCMAKE_INSTALL_COMPONENT=cxx-headers
   -P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
Index: libcxx/trunk/lib/CMakeLists.txt
===
--- libcxx/trunk/lib/CMakeLists.txt
+++ libcxx/trunk/lib/CMakeLists.txt
@@ -286,7 +286,7 @@
 endif()
 
 # Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS cxx_headers ${LIBCXX_TARGETS})
+add_custom_target(cxx DEPENDS cxx-headers ${LIBCXX_TARGETS})
 
 if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
   file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82699: [driver][arm64] Set target CPU to A12 for compiler invocations that target Apple Silicon

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

In D82699#2118313 , @arphaman wrote:

> @t.p.northover @ab I noticed that the use of "apple-a12" doesn't infer the 
> right target features when we're passing in a11 or older, so that's why my 
> test file has the `INFER-A12` separate line. Do you think this is a bug? This 
> is decided here:
>
>   else if ((A = Args.getLastArg(options::OPT_mcpu_EQ)))
> success = getAArch64ArchFeaturesFromMcpu(D, A->getValue(), Args, 
> Features);
>   
>
> and CPU value isn't checked here.


Interesting.  Does it even pass the newer CPU then?  If so I imagine the 
features are still enabled in the backend because of the cpu, so this would 
only affect frontend behavior (e.g., preprocessor macros, which might in turn 
affect some intrinsic headers, etc..).  Either way, I agree it's a bug

But the apple-a12 floor isn't a hard requirement here (unlike e.g., arm64e 
where we'll fail to compile without certain features), so I'm tempted to avoid 
these shenanigans entirely and let users specify what they want.  What do you 
think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82699



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

[PATCH] D78252: [AArch64] FMLA/FMLS patterns improvement.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:8058
+  def : Pat<(v8f16 (OpNode (v8f16 V128:$Rd), (v8f16 V128:$Rn),
+   (AArch64duplane16 (v8f16 V128:$Rm),
+   VectorIndexH:$idx))),

Should this be V128_lo?  I don't think this is encodable for Rm in V16-V31  
(same in the other indexed f16 variants I think)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78252



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

[PATCH] D78252: [AArch64] FMLA/FMLS patterns improvement.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:8058
+  def : Pat<(v8f16 (OpNode (v8f16 V128:$Rd), (v8f16 V128:$Rn),
+   (AArch64duplane16 (v8f16 V128:$Rm),
+   VectorIndexH:$idx))),

ilinpv wrote:
> ab wrote:
> > Should this be V128_lo?  I don't think this is encodable for Rm in V16-V31  
> > (same in the other indexed f16 variants I think)
> Yep, I double checked encoding, you are right. Thank you very much for this. 
> Fixed in 4eca1c06a4a9183fcf7bb230d894617caf3cf3be
Thanks Pavel!  I think this applies to the `AArch64dup` variants too, which 
does entail adding `FPR16Op_lo` and `FPR16_lo` I imagine, and maybe a couple 
more


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78252



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

[PATCH] D119788: [AArch64] Add support for -march=native for Apple M1 CPU

[Ahmed Bougacha via Phabricator via cfe-commits]

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

Reading this again, I have a feeling defaulting to newest will come back to 
bite us (or, well, apple folks.)   But we can reevaluate if we get to that.  
So, LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119788

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

[PATCH] D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab updated this revision to Diff 292557.
ab added a comment.
Herald added a subscriber: pzheng.

Reformat ValidArchs.


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

https://reviews.llvm.org/D87095

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arclite-link.c
  clang/test/Driver/target-triple-deployment.c
  clang/test/Preprocessor/arm64e.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/BinaryFormat/MachO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/LTOModule.cpp
  llvm/lib/Object/MachOObjectFile.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
  llvm/test/MC/AArch64/arm64e-subtype.s
  llvm/test/MC/AArch64/arm64e.s
  llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
  llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
  llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
  llvm/test/tools/llvm-readobj/macho-arm64e.test
  llvm/unittests/ADT/TripleTest.cpp
  llvm/utils/UpdateTestChecks/asm.py

Index: llvm/utils/UpdateTestChecks/asm.py
===
--- llvm/utils/UpdateTestChecks/asm.py
+++ llvm/utils/UpdateTestChecks/asm.py
@@ -335,6 +335,7 @@
   'amdgcn': (scrub_asm_amdgpu, ASM_FUNCTION_AMDGPU_RE),
   'arm': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_RE),
   'arm64': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_RE),
+  'arm64e': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'arm64-apple-ios': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'armv7-apple-ios' : (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_IOS_RE),
   'armv7-apple-darwin': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_DARWIN_RE),
Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1590,5 +1590,10 @@
 Triple T = Triple("aarch64_be");
 EXPECT_EQ(Triple::aarch64_be, T.getArch());
   }
+  {
+Triple T = Triple("arm64e");
+EXPECT_EQ(Triple::aarch64, T.getArch());
+EXPECT_EQ(Triple::AArch64SubArch_arm64e, T.getSubArch());
+  }
 }
 } // end anonymous namespace
Index: llvm/test/tools/llvm-readobj/macho-arm64e.test
===
--- /dev/null
+++ llvm/test/tools/llvm-readobj/macho-arm64e.test
@@ -0,0 +1,17 @@
+# RUN: yaml2obj %s -o %t.o
+# RUN: llvm-readobj -h %t.o | FileCheck %s
+
+# CHECK: Magic: Magic64 (0xFEEDFACF)
+# CHECK: CpuType: Arm64 (0x10C)
+# CHECK: CpuSubType: CPU_SUBTYPE_ARM64E (0x2)
+
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x010C
+  cpusubtype:  0x0002
+  filetype:0x0001
+  ncmds:   0
+  sizeofcmds:  0
+  flags:   0x
+  reserved:0x
Index: llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
===
--- llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
+++ llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
@@ -22,7 +22,7 @@
 # CHECK-NEXT: offset 16384
 # CHECK-NEXT: size 384
 # CHECK-NEXT: align 2^14 (16384)
-# CHECK-NEXT: architecture
+# CHECK-NEXT: architecture arm64e
 # CHECK-NEXT: cputype CPU_TYPE_ARM64
 # CHECK-NEXT: cpusubtype CPU_SUBTYPE_ARM64E
 # CHECK-NEXT: capabilities 0x0
Index: llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
===
--- /dev/null
+++ llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
@@ -0,0 +1,17 @@
+; RUN: llc -O0 %s -filetype=obj -o - \
+; RUN:   | llvm-dwarfdump -arch arm64e - | FileCheck %s
+; CHECK: file format Mach-O arm64
+
+source_filename = "/tmp/empty.c"
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "arm64e-apple-ios"
+
+!llvm.module.flags = !{!1, !2, !3, !4}
+!llvm.dbg.cu = !{!5}
+
+!1 = !{i32 2, !"Dwarf Version", i32 4}
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = !{i32 1, !"wchar_size", i32 4}
+!4 = !{i32 7, !"PIC Level", i32 2}
+!5 = distinct !DICompileUnit(language: DW_LANG_C99, file: !6, producer: "Apple clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug)
+!6 = !DIFile(filename: "/tmp/empty.c", directory: "/Volumes/Data/llvm-project")
Index: llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
===
--- llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
+++ llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
@@ -1,16 +1,39 @@
 // RUN: llvm-mc -triple arm64-apple-macos10.10.2 %s -filetype=obj -o - | llvm-objdump --macho --private-headers - | FileC

[PATCH] D86105: [darwin] Disable the -Wpsabi warning

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

Hmm, is there a more general way to disable warnings?  I'm not familiar with 
these parts, so I'll defer to you folks =]




Comment at: clang/lib/CodeGen/TargetInfo.cpp:2515-2516
+  if (!CallerHasFeat && !CalleeHasFeat) {
+// Darwin doesn't enable AVX/AVX512 by default to support Rosetta 2, so 
it's
+// user's responsibility to use AVX/AVX512 safely.
+if (TT.isOSDarwin())

I wouldn't explain it this way, maybe something like ^ ?



Comment at: clang/lib/CodeGen/TargetInfo.cpp:2561-2565
 // The "avx" feature changes how vectors >128 in size are passed. "avx512f"
 // additionally changes how vectors >256 in size are passed. Like GCC, we
 // warn when a function is called with an argument where this will change.
 // Unlike GCC, we also error when it is an obvious ABI mismatch, that is,
 // the caller and callee features are mismatched.

also very minor nitpick: if you pass around some WarnOnSSE bool or something, 
you'd have the darwin explanation with this psABI comment here, might be nicer


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

https://reviews.llvm.org/D86105

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

[PATCH] D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
Herald added subscribers: cfe-commits, danielkiss, cmtice, rupprecht, 
dexonsmith, steven_wu, hiraditya, kristof.beyls, arichardson.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
Herald added projects: clang, LLVM.
ab requested review of this revision.
Herald added a subscriber: ormris.

This is the first of many Pointer Authentication-related patches we're happy to 
finally upstream =]
For a high-level overview, see our llvm-dev RFC: 
http://lists.llvm.org/pipermail/llvm-dev/2019-October/136091.html, as well as 
the devmtg talk we did at the same time last year.
For concrete code that builds on this, see the staging PR in 
apple/llvm-project: https://github.com/apple/llvm-project/pull/14.  Though 
we've made changes downstream since then, the general concepts and added 
constructs are mostly identical.

Per commit message:

  This also teaches MachO writers/readers about the MachO cpu subtype,
  beyond the minimal subtype reader support present at the moment.
  
  This also defines a preprocessor macro to allow users to distinguish
  __arm64__ from __arm64e__.
  
  arm64e defaults to an "apple-a12" CPU, which supports v8.3a, allowing
  pointer-authentication codegen.
  It also currently defaults to ios14+ and macos11+.

If it helps, we can obviously split this patch further, but I feel like this 
all belongs together, as the core boilerplate needed for new (darwin) targets.

Note that this adds a `Triple::isArm64e()`, which is a bit of a departure from 
prior subarches, in part because we check it more often.  The obvious 
alternative would be to compare `Triple::getArchName()` with "arm64e";  I'm 
fine with either.   However, I would like to preserve the "arm64e" naming, as 
we refer to that extensively in Darwin-land.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87095

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arclite-link.c
  clang/test/Driver/target-triple-deployment.c
  clang/test/Preprocessor/arm64e.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/BinaryFormat/MachO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/LTOModule.cpp
  llvm/lib/Object/MachOObjectFile.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
  llvm/test/MC/AArch64/arm64e-subtype.s
  llvm/test/MC/AArch64/arm64e.s
  llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
  llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
  llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
  llvm/test/tools/llvm-readobj/macho-arm64e.test
  llvm/unittests/ADT/TripleTest.cpp
  llvm/utils/UpdateTestChecks/asm.py

Index: llvm/utils/UpdateTestChecks/asm.py
===
--- llvm/utils/UpdateTestChecks/asm.py
+++ llvm/utils/UpdateTestChecks/asm.py
@@ -335,6 +335,7 @@
   'amdgcn': (scrub_asm_amdgpu, ASM_FUNCTION_AMDGPU_RE),
   'arm': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_RE),
   'arm64': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_RE),
+  'arm64e': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'arm64-apple-ios': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'armv7-apple-ios' : (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_IOS_RE),
   'armv7-apple-darwin': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_DARWIN_RE),
Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1590,5 +1590,10 @@
 Triple T = Triple("aarch64_be");
 EXPECT_EQ(Triple::aarch64_be, T.getArch());
   }
+  {
+Triple T = Triple("arm64e");
+EXPECT_EQ(Triple::aarch64, T.getArch());
+EXPECT_EQ(Triple::AArch64SubArch_arm64e, T.getSubArch());
+  }
 }
 } // end anonymous namespace
Index: llvm/test/tools/llvm-readobj/macho-arm64e.test
===
--- /dev/null
+++ llvm/test/tools/llvm-readobj/macho-arm64e.test
@@ -0,0 +1,17 @@
+# RUN: yaml2obj %s -o %t.o
+# RUN: llvm-readobj -h %t.o | FileCheck %s
+
+# CHECK: Magic: Magic64 (0xFEEDFACF)
+# CHECK: CpuType: Arm64 (0x10C)
+# CHECK: CpuSubType: CPU_SUBTYPE_ARM64E (0x2)
+
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x010C
+  cpusubtype:  0x0002
+  filetype:0x0001
+  ncmds:   0
+  sizeofcmds:  0
+  flags:   0x
+  reserved:0x
Index: llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
===
--- llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
+++ llvm/test/tools/llvm-objdump/MachO/universal-arm6

[PATCH] D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

In D87095#2255010 , @pcc wrote:

> But I was wondering: shouldn't this be the *last* patch? I was imagining that 
> you would first upstream support for the `-fptrauth-*` flags, and then at the 
> end you would add an `arm64e` subarch that turns them on by default. 
> Otherwise the upstream compiler will temporarily produce ABI-incompatible 
> objects when targeting `arm64e`.

Good point, you're right.  ABI compatibility has obviously been a major issue 
as we keep iterating on this, so we added the concept of ptrauth ABI versions 
to the arm64e mach-o cpusubtype.  With this patch, upstream clang produces 
"unversioned" binaries, which are rejected on macOS11/iOS14.  Once we're done 
upstreaming, I'll make the final patch to match the ABI version.  In the 
meantime, that means upstream can't produce anything that runs on macOS, which 
should avoid this problem (and lets us use arm64e checks in the remaining 
patches, though I can obviously extract that to have the patches done the other 
way)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87095

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

[PATCH] D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.

[Ahmed Bougacha via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf77c948d56b0: [Triple][MachO] Define "arm64e", an 
AArch64 subarch for Pointer Auth. (authored by ab).

Changed prior to commit:
  https://reviews.llvm.org/D87095?vs=292557&id=309261#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87095

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arclite-link.c
  clang/test/Driver/target-triple-deployment.c
  clang/test/Preprocessor/arm64e.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/BinaryFormat/MachO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/LTOModule.cpp
  llvm/lib/Object/MachOObjectFile.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
  llvm/test/MC/AArch64/arm64e-subtype.s
  llvm/test/MC/AArch64/arm64e.s
  llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
  llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
  llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
  llvm/test/tools/llvm-readobj/macho-arm64e.test
  llvm/unittests/ADT/TripleTest.cpp
  llvm/utils/UpdateTestChecks/asm.py

Index: llvm/utils/UpdateTestChecks/asm.py
===
--- llvm/utils/UpdateTestChecks/asm.py
+++ llvm/utils/UpdateTestChecks/asm.py
@@ -336,6 +336,7 @@
   'amdgcn': (scrub_asm_amdgpu, ASM_FUNCTION_AMDGPU_RE),
   'arm': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_RE),
   'arm64': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_RE),
+  'arm64e': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'arm64-apple-ios': (scrub_asm_arm_eabi, ASM_FUNCTION_AARCH64_DARWIN_RE),
   'armv7-apple-ios' : (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_IOS_RE),
   'armv7-apple-darwin': (scrub_asm_arm_eabi, ASM_FUNCTION_ARM_DARWIN_RE),
Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1590,5 +1590,10 @@
 Triple T = Triple("aarch64_be");
 EXPECT_EQ(Triple::aarch64_be, T.getArch());
   }
+  {
+Triple T = Triple("arm64e");
+EXPECT_EQ(Triple::aarch64, T.getArch());
+EXPECT_EQ(Triple::AArch64SubArch_arm64e, T.getSubArch());
+  }
 }
 } // end anonymous namespace
Index: llvm/test/tools/llvm-readobj/macho-arm64e.test
===
--- /dev/null
+++ llvm/test/tools/llvm-readobj/macho-arm64e.test
@@ -0,0 +1,17 @@
+# RUN: yaml2obj %s -o %t.o
+# RUN: llvm-readobj -h %t.o | FileCheck %s
+
+# CHECK: Magic: Magic64 (0xFEEDFACF)
+# CHECK: CpuType: Arm64 (0x10C)
+# CHECK: CpuSubType: CPU_SUBTYPE_ARM64E (0x2)
+
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x010C
+  cpusubtype:  0x0002
+  filetype:0x0001
+  ncmds:   0
+  sizeofcmds:  0
+  flags:   0x
+  reserved:0x
Index: llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
===
--- llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
+++ llvm/test/tools/llvm-objdump/MachO/universal-arm64.test
@@ -22,7 +22,7 @@
 # CHECK-NEXT: offset 16384
 # CHECK-NEXT: size 384
 # CHECK-NEXT: align 2^14 (16384)
-# CHECK-NEXT: architecture
+# CHECK-NEXT: architecture arm64e
 # CHECK-NEXT: cputype CPU_TYPE_ARM64
 # CHECK-NEXT: cpusubtype CPU_SUBTYPE_ARM64E
 # CHECK-NEXT: capabilities 0x0
Index: llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
===
--- /dev/null
+++ llvm/test/tools/llvm-dwarfdump/AArch64/arm64e.ll
@@ -0,0 +1,17 @@
+; RUN: llc -O0 %s -filetype=obj -o - \
+; RUN:   | llvm-dwarfdump -arch arm64e - | FileCheck %s
+; CHECK: file format Mach-O arm64
+
+source_filename = "/tmp/empty.c"
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "arm64e-apple-ios"
+
+!llvm.module.flags = !{!1, !2, !3, !4}
+!llvm.dbg.cu = !{!5}
+
+!1 = !{i32 2, !"Dwarf Version", i32 4}
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = !{i32 1, !"wchar_size", i32 4}
+!4 = !{i32 7, !"PIC Level", i32 2}
+!5 = distinct !DICompileUnit(language: DW_LANG_C99, file: !6, producer: "Apple clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug)
+!6 = !DIFile(filename: "/tmp/empty.c", directory: "/Volumes/Data/llvm-project")
Index: llvm/test/MC/MachO/AArch64/arm-darwin-version-min-load-command.s
===

[PATCH] D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

Thanks Tim!  f77c948d56b 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87095

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

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab created this revision.
ab added reviewers: rjmccall, ahatanak, bruno, pcc, apazos, kristof.beyls, 
t.p.northover, pbarrio, chill, danielkiss, psmith.
ab added a project: clang.
Herald added subscribers: dexonsmith, zzheng, dang, mgorny.
ab requested review of this revision.

Building on D90868 , this defines the basic 
set of pointer authentication clang builtins (provided in a new header, 
`ptrauth.h`), with diagnostics and IRGen support.
The availability of the builtins is gated on a new flag `-fptrauth-intrinsics`, 
which is enabled by default by the driver for darwin arm64e.

Note that this only includes the basic intrinsics (matching D90868 
), and notably excludes 
`ptrauth_sign_constant`, and 
`ptrauth_type_discriminator`/`ptrauth_string_discriminator`, which need extra 
logic to be fully supported.  If it helps, I can bring the header/sema support 
here so that we can review all builtins together, and do full IRGen later.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression o

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab updated this revision to Diff 384825.
ab marked 3 inline comments as done.
ab added a comment.

Simplify `err_ptrauth_disabled` diagnostic, rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression of type}}
+}
+
+void test_sign_unauthenticated(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY); // expected-error {{too few arguments}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, dp, dp); // expected-error {{too many arguments}}
+
+  __builtin_ptrauth_sign_unauthenticated(mismatched_type, VALID_DATA_KEY, 0); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, mismatched_type, 0); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, mismatched_type); // expected-error {{extra discriminator must have pointer or integer type; type here is 'struct A'}}
+
+  (void) __

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab updated this revision to Diff 384827.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression of type}}
+}
+
+void test_sign_unauthenticated(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY); // expected-error {{too few arguments}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, dp, dp); // expected-error {{too many arguments}}
+
+  __builtin_ptrauth_sign_unauthenticated(mismatched_type, VALID_DATA_KEY, 0); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, mismatched_type, 0); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, mismatched_type); // expected-error {{extra discriminator must have pointer or integer type; type here is 'struct A'}}
+
+  (void) __builtin_ptrauth_sign_unauthenticated(NULL, VALID_DATA_KEY, 0); // expected-warning {{signing a null pointer wil

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

In D112941#3105297 , @tschuett wrote:

> The original `ptrauth.h` has the same comment style. Would doxygen style be 
> an improvement?

Hmm, what do you have in mind?  Markup for the builtin arguments/returns?  The 
need for `__` prefixes makes that a bit awkward, but I suppose that's not a big 
deal (and we do live with that for x86 intrins already)




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:839
+def err_ptrauth_disabled :
+  Error<"pointer authentication is disabled for the current target">;
+def err_ptrauth_invalid_key :

rjmccall wrote:
> apazos wrote:
> > These two error types are confusing. 
> > In which situation would err_ptrauth_disabled be printed?
> > With this patch, it is only supported with arm64e triple, all other targets 
> > it is unsupported.
> We could probably just have one of these, yes.
With this patch you'd get `err_ptrauth_disabled` with `-target arm64e- 
-fno-ptrauth-intrinsics`, instead of `err_ptrauth_disabled_target` with say 
`-target x86_64`.  But yeah, I suppose we could live with only one of the two, 
with a less accurate message (either `err_ptrauth_disabled_target` renamed to 
`err_ptrauth_disabled`, or another more vague message altogether, say "pointer 
authentication is not supported")

This mostly removes the need for `Sema::diagnosePointerAuthDisabled` and 
`TargetInfo::isPointerAuthSupported` and lets us just rely on the individual 
langopts, which seems okay.



Comment at: clang/lib/Basic/Targets/AArch64.cpp:847
+const llvm::APSInt &value) const {
+  return 0 <= value && value <= 3;
+}

rjmccall wrote:
> There's an LLVM constants header for this now, right?
Hmm, I don't think so, do you have something in mind?  The AArch64 backend has 
helpers for this, but that's confined there.  IR doesn't know anything about 
keys (for instance, the IR verifier doesn't have the same validation done here)

There's a related latent concern I have: currently, nothing prevents 
optimizations from moving ptrauth ops into global constant initializers, and 
since we don't support global initializers with process-specific keys (at least 
on darwin), we may need to expose this knowledge somehow (undoing this in the 
backend is not straightforward, but is an option). 

Knowing which keys are used in what way would need to be triple-specific, 
though I guess that's not an obstacle.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

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

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: clang/include/clang/Driver/Options.td:2865-2872
+let Group = f_Group in {
+  let Flags = [CC1Option] in {
+def fptrauth_intrinsics : Flag<["-"], "fptrauth-intrinsics">,
+  HelpText<"Enable pointer-authentication intrinsics">;
+  }
+  def fno_ptrauth_intrinsics : Flag<["-"], "fno-ptrauth-intrinsics">;
+}

rjmccall wrote:
> kristof.beyls wrote:
> > My impression is that generally for `__builtin_XXX` intrinsics, there are 
> > no compiler flags to make them available or remove their availability.
> > Is there a good reason why a command line option is needed for the 
> > `__builtin_ptrauth` intrinsics, but not (IIUC) for most or any other 
> > existing `__builtin_XXX` intrinsic?
> > If there is no good reason, it seems better to me to not have a command 
> > line option so there is better consistency across all `__builtin_XXX` 
> > intrinsics?
> > 
> > (after having read more of the patch): my impression has changed now that 
> > the f(no-)ptrauth-intrinsics flag rather selects whether the ptrauth 
> > intrinsics get lowered to PAuth hardware instructions, or to "regular" 
> > instructions emulating the behavior of authenticated pointers. If that is 
> > correct (and assuming it's a useful option to have), I would guess a 
> > different name for the command line option could be less misleading. As is, 
> > it suggests this selects whether ptrauth_ intrinsics are available or not. 
> > If instead, as I'm guessing above, this selects whether ptrauth_ intrinsics 
> > get lowered to PAuth instructions or not, maybe something like 
> > '-femulate-ptrauth' would describe the effect of the command line switch a 
> > bit better?
> The ptrauth features were implemented gradually, beginning with the 
> intrinsics.  Originally we needed a way to enable the intrinsics feature 
> without relying on target information.  We do still need a way to enable them 
> without necessarily enabling automatic type/qualifier-based pointer 
> authentication.  I don't know if we need to be able to *disable* them when 
> the target supports them; I agree that that would be a little strange.
> 
> If not, we could just enable the intrinsics whenever either the target says 
> they're okay or software emulation (a separate, experimental feature) is 
> enabled.  The AArch64 target has a `+pauth` target feature.  However, I don't 
> know if `-arch arm64e` actually adds that feature on Apple targets.  Also, 
> the `HasPAuth` field in the clang `TargetInfo` does not appear to be properly 
> initialized to `false` when `+pauth` *isn't* present; fortunately, that field 
> never used.
> 
> I'm not sure if it would actually be okay to remove the 
> `-fptrauth-intrinsics` driver option if we just enabled the intrinsics based 
> on the target feature.  That does feel cleaner, but unfortunately, we at 
> Apple probably have explicit uses of the option that we'd have to clean up 
> before we could remove the option.  We could treat that as an Apple problem 
> and keep it out of the open source tree, though, and maybe remove the option 
> altogether someday.
> 
> Ahmed, thoughts?
Hmm, I agree it would be strange to need to disable the intrinsics, but we do 
also gate the various higher-level qualifiers (and intrinsics) on 
`ptrauth_intrinsics`.  So, in `ptrauth.h` (and in various users) the feature 
now really means "we're in a 'ptrauth-aware' environment".  And it does make 
more sense to keep that separate from "we're running on a CPU that 
theoretically could support ptrauth".  It comes down to what "ptrauth-aware" 
really means, and that's probably also an Apple problem, and all current users 
of `ptrauth_intrinsics` should use something like `__arm64e__` instead.

That still means there's no equivalent for other targets and/or software 
emulation, but that seems okay: `ptrauth.h` already needs changes to be usable 
from anywhere other than arm64e (cf. the discussion about keys), and we can 
cross that bridge when we get there.

(One could argue that all the language-feature-specific qualifiers and 
intrinsics should be gated on the appropriate ptrauth_whatever feature, but the 
qualifiers are often used in precisely the glue/runtime code that doesn't build 
in the appropriate mode, so doesn't have the feature enabled.)


So, concretely, we could:
- continue gating these plain intrinsics on `ptrauth_intrinsics` in ptrauth.h 
(IIRC there's an ACLE feature macro but it's specific to return address signing 
and BTI defaults; I'll check)
- enable the feature when `+pauth`
- replace all other uses of `ptrauth_intrinsics` with `__arm64e__`, in both 
ptrauth.h (gating the ABI qualifiers) and gradually in our internal codebases

and keep `-fptrauth-intrinsics` downstream for the transition (or, depending on 
how much the flag is really used, just keep the old behavior of enabling the 
feature for arm64e only;  but yeah, that's my downstream problem)



Comment at

[PATCH] D76062: [PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.
Herald added a subscriber: StephenFan.
Herald added a project: All.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:52
+  AArch64::AEK_RDM  | AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+  AArch64::AEK_SM4  | AArch64::AEK_SHA3 | AArch64::AEK_BF16|
+  AArch64::AEK_SHA2 | AArch64::AEK_AES  | AArch64::AEK_I8MM))

stuij wrote:
> SjoerdMeijer wrote:
> > just double checking (because I can't remember): BF16 is a mandatory 
> > extension?
> for 8.2 it isn't, for 8.6 it is
Belated question: what's the rationale for replacing `AEK_CRYPTO` with 
SM4+SHA3+SHA2(+AES)?  I'm not aware of the required crypto bits changing, but 
maybe I missed something.  There's a related question around how we should deal 
with crypto here in the first place (remove FK, remove the crypto exts?), but 
that seems orthogonal to v8.6a+ vs. v8.5a- implying different crypto extensions.

For context, this comes up in D134351 where specifying `V8_6A` would enable 
SM4, which we don't support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76062

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

[PATCH] D134351: AArch64: add definitions for recent Apple CPUs

[Ahmed Bougacha via Phabricator via cfe-commits]

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

> but in AArch64TargetParser.def, marking them v8.6 brings in support for the 
> SM4 cryptographic hash and we don't actually have that

Huh, I don't understand why, does that ring a bell?  Looks like it's been there 
since v8.6a was added here;  I asked in D76062 
.

Other than that, LGTM; we can go back and change this if we change `V8_6A`


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

https://reviews.llvm.org/D134351

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

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab updated this revision to Diff 556443.
ab added a comment.
Herald added subscribers: llvm-commits, wangpc, MaskRay.
Herald added projects: LLVM, All.

Added the relevant bits of the great documentation John wrote in 
clang/docs/PointerAuthentication.rst.  I tried to trim it down to only the 
general principles and the intrinsics;  some of the discussion around the 
security model is a little ahead of the rest of the changes, but is still seems 
fine with these initial changes.


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

https://reviews.llvm.org/D112941

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/PointerAuthentication.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c
  llvm/docs/PointerAuth.md

Index: llvm/docs/PointerAuth.md
===
--- llvm/docs/PointerAuth.md
+++ llvm/docs/PointerAuth.md
@@ -10,6 +10,9 @@
 signature checked.  This prevents pointer values of unknown origin from being
 used to replace the signed pointer value.
 
+For more details, see the clang documentation page for
+[Pointer Authentication](https://clang.llvm.org/docs/PointerAuthentication.html).
+
 At the IR level, it is represented using:
 
 * a [set of intrinsics](#intrinsics) (to sign/authenticate pointers)
Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = _

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Ahmed Bougacha via Phabricator via cfe-commits]

ab abandoned this revision.
ab added a comment.

This went through so many rebases that the incremental diff is not very helpful 
;)  Let's start over on github:  https://github.com/llvm/llvm-project/pull/65996


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

https://reviews.llvm.org/D112941

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

[PATCH] D70779: AArch64: add support for newer Apple CPUs

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64.td:587
+"Apple A10", [
+ProcAppleA7,
+FeatureCRC,

I'm not sure we want to reuse the features:
- everything will get stuck with FeatureZCZeroingFPWorkaround, right? (but 
maybe we can remove features in this list?  I don't think so)
- it probably becomes harder to tune later chips, but that's admittedly a 
theoretical problem at this point
- some of the features can be generation-specific


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

https://reviews.llvm.org/D70779



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

[PATCH] D70779: AArch64: add support for newer Apple CPUs

[Ahmed Bougacha via Phabricator via cfe-commits]

ab accepted this revision.
ab added a comment.

(but either way, LGTM)




Comment at: llvm/lib/Target/AArch64/AArch64.td:587
+"Apple A10", [
+ProcAppleA7,
+FeatureCRC,

t.p.northover wrote:
> ab wrote:
> > I'm not sure we want to reuse the features:
> > - everything will get stuck with FeatureZCZeroingFPWorkaround, right? (but 
> > maybe we can remove features in this list?  I don't think so)
> > - it probably becomes harder to tune later chips, but that's admittedly a 
> > theoretical problem at this point
> > - some of the features can be generation-specific
> Good points. It's a shame to duplicate everything (and solvable by splitting 
> uArch stuff from the progressive features), but it does seem to be existing 
> practice.
> 
> I'll rework it to be more in line with the others and add a test for the 
> workaround you mentioned; that should have been spotted.
Hmm, how about having these in plain top-level tablegen lists?  That lets you 
do `(sub)`, which might be sufficient


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

https://reviews.llvm.org/D70779



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

[PATCH] D70779: AArch64: add support for newer Apple CPUs

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64.td:587
+"Apple A10", [
+ProcAppleA7,
+FeatureCRC,

ab wrote:
> t.p.northover wrote:
> > ab wrote:
> > > I'm not sure we want to reuse the features:
> > > - everything will get stuck with FeatureZCZeroingFPWorkaround, right? 
> > > (but maybe we can remove features in this list?  I don't think so)
> > > - it probably becomes harder to tune later chips, but that's admittedly a 
> > > theoretical problem at this point
> > > - some of the features can be generation-specific
> > Good points. It's a shame to duplicate everything (and solvable by 
> > splitting uArch stuff from the progressive features), but it does seem to 
> > be existing practice.
> > 
> > I'll rework it to be more in line with the others and add a test for the 
> > workaround you mentioned; that should have been spotted.
> Hmm, how about having these in plain top-level tablegen lists?  That lets you 
> do `(sub)`, which might be sufficient
(I don't think that lets us have these cpu "features" though, but TBH I'm not 
sure what they achieve anyway)


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

https://reviews.llvm.org/D70779



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

[PATCH] D148967: Disable atexit()-based lowering when LTO'ing kernel/kext code

[Ahmed Bougacha via Phabricator via cfe-commits]

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

A comment inline, but LGTM otherwise, thanks!




Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:1208
+  // -disable-atexit-based-global-dtor-lowering CodeGen flag.
+  // report_fatal_error("@llvm.global_dtors should have been lowered already");
 }

stray fatal_error?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148967

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

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2535
 ArgAttrs[FirstIRArg + i] =
 llvm::AttributeSet::get(getLLVMContext(), Attrs);
 }

Hmm, if I'm reading this right, this overwrites the `nonnull dereferenceable 
align` attributes separately computed for `this` around l2335, right? (or 
`inalloca` and `sret` before that)

It sounds like an ancient bug, that's only exposed because `noundef` ends up 
triggering this logic much more often?

Many of our downstream tests hit this. The hacked up patch seems to do the job; 
ideally we'd feed the previously-computed attrs when constructing the 
AttrBuilder (which would also fix the padding argument), but we'd need to match 
up the IR args first.  Maybe that's fine as a special-case for arg 0 though


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105169

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

[PATCH] D119788: [AArch64] Add support for -march=native for Apple M1 CPU

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

In D119788#3331324 , @keith wrote:

> Thanks for the tips! I left the default as generic here, but I totally take 
> your point on defaulting to the newest and I'm happy to update if you feel 
> strongly, lmk what you think

I agree with Tim, this should default to the newest known one.

generic doesn't really make sense for Darwin anyway, the "oldest" sane default 
would probably be cyclone, apple-a12, or apple-m1, depending on the slice and OS




Comment at: llvm/lib/Support/Host.cpp:1303
+#elif defined(__APPLE__) && (defined(__arm__) || defined(__aarch64__))
+#include 
+#include 

Looks like we have the same includes for `computeHostNumPhysicalCores`.  Maybe 
move this to the top of the file, gated with just `__APPLE__`?



Comment at: llvm/lib/Support/Host.cpp:1340
+  case CPUFAMILY_ARM_FIRESTORM_ICESTORM:
+return "apple-m1";
+  default:

jrtc27 wrote:
> Maybe a question for AArch64 maintainers about whether apple-a14 or apple-m1 
> should be used... they're the same thing from the backend's perspective just 
> with different names. Shame the naming doesn't separate out the "generation" 
> from the specific configuration like you see for other backends (apple-aN is 
> almost that as it omits all the bionic etc marketing name fluff, except 
> apple-m1 comes along and ruins that).
Seems fine to stick to the `apple-aNN` names here.  (we already have a similar 
situation with `apple-sN`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119788

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

[PATCH] D100807: [clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target

[Ahmed Bougacha via Phabricator via cfe-commits]

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

Neat, thanks!


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

https://reviews.llvm.org/D100807

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

[PATCH] D100807: [clang][driver] Use the canonical Darwin arch name when printing out the triple for a Darwin target

[Ahmed Bougacha via Phabricator via cfe-commits]

ab added a comment.

This sounds nice!  One idea, maybe more dangerous, not sure which is better:  
in `setTripleTypeForMachOArchName`, we already have a couple `setArchName` 
calls, I think that's why `arm64e` is left alone in the `aarch64-cpus.c` test.  
Maybe we can do the `setArchName` call for every arch there?

Another question, probably a completely separate problem: why is it still 
reporting darwin?  Ideally we'd want it to report macos, right?  With that + 
your change the triple there would be the actual triple we use to build.  (but 
maybe the macos bit only comes later when we pick up an SDK in DarwinClang or 
whatever?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100807

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