Also introduce __builtin_ldexpf16.
Details
Diff Detail
Event Timeline
Can you add a test for CUDA/NVPTX, too?
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
3057–3058 | Should those builtins that map to an experimental intrinsic be experimental, too? Alternatively, if the intrinsic functionality is something we intend to officially provide via clang builtin, should we drop the experimental part? |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
3057–3058 | They only map to experimental intrinsics if you use the still fairly new FENV_ACCESS support. So I'd say no to marking them experimental. Most users of them will not encounter any experimental support. I'm still working on getting the IR Verifier changes into the tree. At the very least I don't think we should be dropping the experimental from the names of the constrained intrinsics when there's no checking at all for violations of the rules of using them. |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
3057–3058 | It's not a constrained builtin, it's constrained handling for a builtin. Certainly part of the experimental part is that we only have patchwork support for strictfp for all of the builtins. |
There's nothing target specific here and I don't see a pre-existing test for nvptx generic builtin handling
You're right. My concern is actually about handling the intrinsics, not the builtins and is irrelevant for this patch.
Should those builtins that map to an experimental intrinsic be experimental, too?
Alternatively, if the intrinsic functionality is something we intend to officially provide via clang builtin, should we drop the experimental part?