https://github.com/wsmoses created
https://github.com/llvm/llvm-project/pull/83059
This PR adds functionality for specifying an LLVM function attribute within
clang. This is necessary for transfering information from C++ into LLVM which
doens't have a C++-level attribute. This functionality ha
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
@llvm/pr-subscribers-clang
Author: William Moses (wsmoses)
Changes
This PR adds functionality for specifying an LLVM function attribute within
clang. This is necessary for transfering information from C++ into LLVM which
doens't have a C+
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 99335a646bc0b10066d77cec08ae8cab0162efde
0afeea9dcc8b02ade26e6ec0652ae1fa6ec33a7c --
https://github.com/wsmoses updated
https://github.com/llvm/llvm-project/pull/83059
>From b6ab7f38406cd51670bd2a1253142243cf80a433 Mon Sep 17 00:00:00 2001
From: "William S. Moses"
Date: Mon, 26 Feb 2024 16:17:55 -0500
Subject: [PATCH] [Clang][HTO] Add clang attribute for propagating llvm-level
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -emit-llvm -o - | FileCheck %s
+
+void t1() __attribute__((llvm_fn_attr("custom_attr", "custom_value"),
llvm_fn_attr("second_attr", "second_value")));
+
+void t1()
+{
+}
+
+void t2();
+
+void t3() {
+ t2() at
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -emit-llvm -o - | FileCheck %s
+
+void t1() __attribute__((llvm_fn_attr("custom_attr", "custom_value"),
llvm_fn_attr("second_attr", "second_value")));
+
+void t1()
+{
+}
+
+void t2();
+
+void t3() {
+ t2() at
https://github.com/wsmoses updated
https://github.com/llvm/llvm-project/pull/83059
>From c01b559836ca62648c5f95a6441888514347a1ea Mon Sep 17 00:00:00 2001
From: "William S. Moses"
Date: Mon, 26 Feb 2024 16:17:55 -0500
Subject: [PATCH] [Clang][HTO] Add clang attribute for propagating llvm-level
https://github.com/wsmoses updated
https://github.com/llvm/llvm-project/pull/83059
>From c01b559836ca62648c5f95a6441888514347a1ea Mon Sep 17 00:00:00 2001
From: "William S. Moses"
Date: Mon, 26 Feb 2024 16:17:55 -0500
Subject: [PATCH 1/2] [Clang][HTO] Add clang attribute for propagating
llvm-l
https://github.com/wsmoses updated
https://github.com/llvm/llvm-project/pull/83059
>From c01b559836ca62648c5f95a6441888514347a1ea Mon Sep 17 00:00:00 2001
From: "William S. Moses"
Date: Mon, 26 Feb 2024 16:17:55 -0500
Subject: [PATCH 1/2] [Clang][HTO] Add clang attribute for propagating
llvm-l
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -emit-llvm -o - | FileCheck %s
+
+void t1() __attribute__((llvm_fn_attr("custom_attr", "custom_value"),
llvm_fn_attr("second_attr", "second_value")));
+
+void t1()
+{
+}
+
+void t2();
+
+void t3() {
+ t2() at
https://github.com/wsmoses updated
https://github.com/llvm/llvm-project/pull/83059
>From c01b559836ca62648c5f95a6441888514347a1ea Mon Sep 17 00:00:00 2001
From: "William S. Moses"
Date: Mon, 26 Feb 2024 16:17:55 -0500
Subject: [PATCH 1/2] [Clang][HTO] Add clang attribute for propagating
llvm-l
https://github.com/AaronBallman requested changes to this pull request.
Thank you for working on this, but I'm generally not in favor of this patch. I
do not think we should expose all LLVM IR (function) attributes directly in
Clang for a whole host of reasons:
* User experience is very poor.
https://github.com/erichkeane commented:
There are a few things in how the `handle` function works that are
incorrect/not necessary, but like Aaron, I'm pretty solidly against this patch
in concept. Aaron had some good reasoning, and mine opinion reflects all of it.
https://github.com/llvm/ll
wsmoses wrote:
@AaronBallman @erichkeane, do you have any suggestions for paths forward, for
use cases where it is guaranteed that the attribute is valid and the user (or
perhaps more specifically, another Clang-tool) needs to provide information to
LLVM through Clang AST/source.
For example,
wsmoses wrote:
As another option, what if this always emits string attributes prefixed with
"clang_". And any other tools that semantic assurances for what they do with
it. Thus the attribute won't be tied to any LLVM attributes.
https://github.com/llvm/llvm-project/pull/83059
erichkeane wrote:
> @AaronBallman @erichkeane, do you have any suggestions for paths forward, for
> use cases where it is guaranteed that the attribute is valid and the user (or
> perhaps more specifically, another Clang-tool) needs to provide information
> to LLVM through Clang AST/source.
>
wsmoses wrote:
So my understanding was that the annotate attribute didn't modify codegen (and
thus LLVM string attributes), but perhaps I didn't use it properly.
Is there any reference for that?
https://github.com/llvm/llvm-project/pull/83059
___
cfe
erichkeane wrote:
> So my understanding was that the annotate attribute didn't modify codegen
> (and thus LLVM string attributes), but perhaps I didn't use it properly.
>
> Is there any reference for that?
I'm not sure what you mean by that? the 'annotate' attribute just ends up in
an LLVM-s
https://github.com/wsmoses closed
https://github.com/llvm/llvm-project/pull/83059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
wsmoses wrote:
Okay, the AnnotateAttr doesn't create LLVM string attributes, it creates LLVM
metadata, but that should sufice, closing.
https://github.com/llvm/llvm-project/pull/83059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
wsmoses wrote:
Hm actually reopening, for some reason the metadata isn't being pushed at O0.
https://github.com/llvm/llvm-project/pull/83059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/wsmoses reopened
https://github.com/llvm/llvm-project/pull/83059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Hm actually reopening, the metadata isn't emitted if the defnition isn't
> available [e.g. for `extern int X;` when given an annotation
That seems like a bug (so long as the declaration is actually emitted to LLVM
IR at all).
> @AaronBallman @erichkeane, do you have any
erichkeane wrote:
> > Hm actually reopening, the metadata isn't emitted if the defnition isn't
> > available [e.g. for `extern int X;` when given an annotation
>
> That seems like a bug (so long as the declaration is actually emitted to LLVM
> IR at all).
>
> > @AaronBallman @erichkeane, do y
24 matches
Mail list logo