https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/74737
>From 4264e7e9c7f655f134623d113ba9dccc5564f4c3 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Thu, 7 Dec 2023 11:45:14 -0500
Subject: [PATCH] [AMDGPU] add function attrbute amdgpu-lib-fun
Add a function
@@ -2693,6 +2693,17 @@ An error will be given if:
}];
}
+def AMDGPULibFunDocs : Documentation {
+ let Category = DocCatAMDGPUAttributes;
+ let Content = [{
+The ``amdgpu_lib_fun`` attribute can be applied to a function for AMDGPU target
+to indicate it is a library functio
@@ -2011,6 +2011,13 @@ def AMDGPUNumVGPR : InheritableAttr {
let Subjects = SubjectList<[Function], ErrorDiag, "kernel functions">;
}
+def AMDGPULibFun : InheritableAttr {
yxsamliu wrote:
will do
https://github.com/llvm/llvm-project/pull/74737
yxsamliu wrote:
> > > > An AMDGPU library function is not internalized and can be used to
> > > > fullfill calls generated by LLVM passes or instruction selection.
> > >
> > >
> > > I am confused by the description of "internalized". Do you refer to LTO
> > > internalization? You can leverage
jhuber6 wrote:
> > > An AMDGPU library function is not internalized and can be used to
> > > fullfill calls generated by LLVM passes or instruction selection.
> >
> >
> > I am confused by the description of "internalized". Do you refer to LTO
> > internalization? You can leverage `llvm.used`
yxsamliu wrote:
> > An AMDGPU library function is not internalized and can be used to fullfill
> > calls generated by LLVM passes or instruction selection.
>
> I am confused by the description of "internalized". Do you refer to LTO
> internalization? You can leverage `llvm.used` to disable LTO
jhuber6 wrote:
> > An AMDGPU library function is not internalized and can be used to fullfill
> > calls generated by LLVM passes or instruction selection.
>
> I am confused by the description of "internalized". Do you refer to LTO
> internalization? You can leverage `llvm.used` to disable LTO
@@ -2011,6 +2011,13 @@ def AMDGPUNumVGPR : InheritableAttr {
let Subjects = SubjectList<[Function], ErrorDiag, "kernel functions">;
}
+def AMDGPULibFun : InheritableAttr {
jhuber6 wrote:
Why isn't this a `TargetSpecificAttr`? We should have one for AMDGPU.
@@ -2693,6 +2693,17 @@ An error will be given if:
}];
}
+def AMDGPULibFunDocs : Documentation {
+ let Category = DocCatAMDGPUAttributes;
+ let Content = [{
+The ``amdgpu_lib_fun`` attribute can be applied to a function for AMDGPU target
+to indicate it is a library functio
MaskRay wrote:
> An AMDGPU library function is not internalized and can be used to fullfill
> calls generated by LLVM passes or instruction selection.
I am confused by the description of "internalized". Do you refer to LTO
internalization? You can leverage `llvm.used` to disable LTO internaliz
jhuber6 wrote:
> I was thinking of implementing libm/libc for nvptx, which would produce an IR
> library . We'll still need to keep the functions around if they are not used
> explicitly, because we may need them to fulfill libcalls later in the
> compilation pipeline. Sort of a libdevice repl
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/74737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
I was thinking of implementing libm/libc for nvptx, which would produce an IR
library . We'll still need to keep the functions around if they are not used
explicitly, because we may need them to fulfill libcalls later in the
compilation pipeline. Sort of a libdevice replacement
jhuber6 wrote:
My use-case is more to be able to write functions like `is_wavefrontsize64()`
in regular C++ code. This would require some way to emit builtins for these.
I believe the use-case here is a workaround for the issues caused by library
ordering? I'm guessing this is related to the p
Artem-B wrote:
This sounds like it may be useful outside of AMDGPU back-end.
@jhuber6 this is something that may come handy for implementing general library
functions.
https://github.com/llvm/llvm-project/pull/74737
___
cfe-commits mailing list
cfe-c
yxsamliu wrote:
ping
https://github.com/llvm/llvm-project/pull/74737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
yxsamliu wrote:
this patch is used by https://github.com/llvm/llvm-project/pull/74741
https://github.com/llvm/llvm-project/pull/74737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/74737
>From b4a30a6c89e59f11368fb71040539d24cacccbfc Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Thu, 7 Dec 2023 11:45:14 -0500
Subject: [PATCH] [AMDGPU] add function attrbute amdgpu-lib-fun
Add a function
llvmbot wrote:
@llvm/pr-subscribers-backend-amdgpu
Author: Yaxun (Sam) Liu (yxsamliu)
Changes
Add a function attribute "amdgpu-lib-fun" to indicate that the function needs
special handling in backend. Basically it will not be internalized so that it
will not be removed by DCE after inter
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Yaxun (Sam) Liu (yxsamliu)
Changes
Add a function attribute "amdgpu-lib-fun" to indicate that the function needs
special handling in backend. Basically it will not be internalized so that it
will not be removed by DCE after internalizatio
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Yaxun (Sam) Liu (yxsamliu)
Changes
Add a function attribute "amdgpu-lib-fun" to indicate that the function needs
special handling in backend. Basically it will not be internalized so that it
will not be removed by DCE after intern
https://github.com/yxsamliu created
https://github.com/llvm/llvm-project/pull/74737
Add a function attribute "amdgpu-lib-fun" to indicate that the function needs
special handling in backend. Basically it will not be internalized so that it
will not be removed by DCE after internalization. This
22 matches
Mail list logo
