AaronBallman wrote: > Thanks for the comments @AaronBallman. The core issue here is that the > current builtin handling design does not allow multiple overloads for the > same identifier to coexist (ref. > > https://github.com/llvm/llvm-project/blob/eacda36c7dd842cb15c0c954eda74b67d0c73814/clang/include/clang/Basic/Builtins.h#L66 > ), unless the builtins are defined in target specific namespaces which is > what I tried in my original patch . If we want change this approach, I > currently think of couple of ways at a top level > > 1. As you said, we could have OCL specific LibBuiltin and LangBuiltin > TableGen classes (and corresponding macros in Buitlins.inc). To make this > work they would need new builtin ID's of different form (say > "BI_OCL##identifier"). This is very Language specific. > > 2. Probably change the current Builtin Info structure to allow vector of > possible signatures for an identifier. The builtin type decoder could choose > the appropriate signature based on LangOpt. (This wording is vague and could > be a separate discussion in itself ) > > > either way, changes in current design are required. printf is the only > current use case I know that can benefit out of this (since OpenCL v1.2 > s6.9.f says other library functions defined in C standard header are not > available ,so 🤷♂️ ). But I guess we could have more use cases in future. can > this be a separate discussion ? This patch would unblock my current work for > now.
I looked at the OpenCL spec for C standard library support and was surprised that 1) it's only talking about C99 so it's unclear what happens for C11 (clause 6 says "This document describes the modifications and restrictions to C99 and C11 in OpenCL C" but 6.11 only talks about C99 headers and leaves `iso646.h`, `math.h`, `stdbool.h`, `stddef.h`, (all in C99) as well as `stdalign.h`, `stdatomic.h`, `stdnoreturn.h`, `threads.h`, and `uchar.h` available?), and 2) OpenCL's `printf` is not really the same function as C's `printf` (https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#differences-between-opencl-c-and-c99-printf). #1 is probably more of an oversight than anything, at least with the C11 headers. So maybe this isn't a super slippery slope, but maybe C23 will change that (I can imagine `stdbit.h` being of use in OpenCL for bit-bashing operations). However, the fact that the builtin isn't really `printf` but is `printf`-like makes me think we should make it a separate builtin to avoid surprises (we do diagnostics based on builtin IDs and we have special checking logic that we perhaps should be exempting in some cases). https://github.com/llvm/llvm-project/pull/86801 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
