[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL builtins
+ set( opencl_opt_flags "--passes=always-inline" )
karolherbst wrote:
An alternative good solution would be to have things like `HAVE_HW_FMA32()`
compiling to a SPIR-V specialization constant and then we just specialize the
SPIR-V, but I'm not sure if it's worth the effort.
But of course things here could also be more formalized for libclc compiled to
a generic SPIR-V binary.
There are many possible paths to make it "proper".
But anyway, I'm not in the mood to discuss this any further with this kind of
attitude, soo.. have fun.
https://github.com/llvm/llvm-project/pull/115699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL builtins
+ set( opencl_opt_flags "--passes=always-inline" )
karolherbst wrote:
yeah, as long as the OpenCL C builtins aren't inlined into the implementations
of other builtins (e.g. a builtin implemented using `fma`) we are fine with any
internal inlining, just want to keep the calls to OpenCL C builtins there.
And one thing I forgot to mention is, that we rely on the function name
mangling to do our custom function lookup/linking, but I guess this won't be
touched by any of this here.
https://github.com/llvm/llvm-project/pull/115699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL builtins
+ set( opencl_opt_flags "--passes=always-inline" )
karolherbst wrote:
Yeah, we in mesa we can map all those SPIR-V CL ExtInst to either a libclc
spir-v implementation or something mesa implementation defined.
There is also like the problem with `fma`, which should never get inlined no
matter what, because some devices might actually need the emulation, so it's
either having two or mor spir-vs (with fma emulation enabled/disabled and
potential other options) or one for everything and we just pick whatever we
need.
We aren't linking against the libclc SPIR-V on a SPIR-V level, but do it way
later, so we have way more flexibility here and can cope with a single variant.
However, that relies on builtins not being inlined into other bultins
implementations.
Besides that one we are fine with optimizations as long as the SPIR-V remains
valid, which if you enable LLVM optimizations isn't simply the case anymore and
the SPIRV-LLVM-Translator ends up generating invalid SPIR-V. But this is
another issue.
https://github.com/llvm/llvm-project/pull/115699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
https://github.com/karolherbst edited https://github.com/llvm/llvm-project/pull/115699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
https://github.com/karolherbst edited https://github.com/llvm/llvm-project/pull/115699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
https://github.com/karolherbst edited https://github.com/llvm/llvm-project/pull/115699 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move several integer functions to CLC library (PR #116786)
@@ -0,0 +1,21 @@ +#ifndef __CLC_INTEGER_CLC_CLZ_H__ +#define __CLC_INTEGER_CLC_CLZ_H__ + +#if defined(CLC_CLSPV) || defined(CLC_SPIRV) +// clspv and spir-v targets provide their own OpenCL-compatible clz +#define __clc_clz clz karolherbst wrote: similar here https://github.com/llvm/llvm-project/pull/116786 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move several integer functions to CLC library (PR #116786)
https://github.com/karolherbst edited https://github.com/llvm/llvm-project/pull/116786 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Move sign to the CLC builtins library (PR #115699)
@@ -322,22 +322,26 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if ( ARCH STREQUAL spirv OR ARCH STREQUAL spirv64 )
set( build_flags -O0 -finline-hint-functions -DCLC_SPIRV )
- set( opt_flags )
+ set( clc_opt_flags )
+ # Inline CLC functions into OpenCL builtins
+ set( opencl_opt_flags "--passes=always-inline" )
karolherbst wrote:
`fma` was just an example and that's already done like that. In the SPIR-V we
see `OpExtInst` for it and others. For builtins where no such intrinsic exists
the `SPIRV-LLVM-Translator` converts those function calls to `OpExtInst` by
demangling the function name and match it against an internal list of names.
Of course all the OpenCL C builtins could be turned into their own intrinsics
and the need for translating from function call to builtin could be dropped,
but the code already exists and it wouldn't necessarily improve the final
SPIR-V in any way.
Anyway, feel free to ask questions if you aren't familiar enough with the
situation and problems we are dealing with here and I'm happy to explain those
things. And we are entirely open to suggestions on how to improve those things
or how to formalize it so it's not just a relied upon implementation detail.
https://github.com/llvm/llvm-project/pull/115699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Stop installing CLC headers (PR #126908)
karolherbst wrote: > > Maybe there is a better tripple to be used in this case? However we do want > > to compile to SPIR-V (with the native target in the future anyway), it's > > just it enables a bunch of things automatically. > > I'm not sure I understand what the issue is. The defines here just declare > that the extension is available, it does not enable them. You need to use the > pragma to actually enable the extension (which the header does to enable > required types later on in that file for declarations, but it cleans up after > itself with `#pragma OPENCL EXTENSION all : disable` at the end > > clang already does have -cl-ext for enabling / disabling extensions on the > command line, I'm not sure if we have an equivalent for changing the target's > reported set ah yeah, that's what I meant. Like if you are a normal CLI user and compile to SPIR-V I think it's reasonable to do it like that, just for users like mesa who actually implement an OpenCL runtime, we have to be very selective about what to advertise to conform to the OpenCL and OpenCL C spec as the official conformance test suite checks if API queries match what defines are enabled at compile time at runtime. So far simply adding `__SPIR__` and `__SPIRV__` to the undefs solves this problem for us. But if there are others doing similar things, they might want to know about this, though most might just compile to a hardware target and never run into this issue in the first place. https://github.com/llvm/llvm-project/pull/126908 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Stop installing CLC headers (PR #126908)
karolherbst wrote: Forgot to drop a link to the lines in question: https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/opencl-c-base.h#L16 https://github.com/llvm/llvm-project/pull/126908 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Stop installing CLC headers (PR #126908)
karolherbst wrote: The base header enables a bunch of extensions when `__SPIRV__` or `__SPIR__` is found, and that define is set automatically when a SPIRV or SPIR tripple is used. Maybe there is a better tripple to be used in this case? However we do want to compile to SPIR-V (with the native target in the future anyway), it's just it enables a bunch of things automatically. I think it's fine to do it that way, it's just a bit of surprising behavior if you want to have tight control over what extensions are enabled or not. https://github.com/llvm/llvm-project/pull/126908 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] libclc: erfc: fix fp32 implementation (PR #132390)
karolherbst wrote: It does, thank you! https://github.com/llvm/llvm-project/pull/132390 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
