This is an archive of the discontinued LLVM Phabricator instance.

[clang][Interp] Support __builtin_clz calls
AbandonedPublic

Authored by tbaeder on Sep 30 2022, 6:36 AM.

Details

Summary

I was wondering how to best implement builtin function calls, but I don't think actually generating bytecode for them makes much sense.

Diff Detail

Event Timeline

tbaeder created this revision.Sep 30 2022, 6:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2022, 6:36 AM
tbaeder requested review of this revision.Sep 30 2022, 6:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2022, 6:36 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
tbaeder added inline comments.Sep 30 2022, 6:36 AM
clang/lib/AST/Interp/InterpBuiltin.cpp
16–19

This would also work as:

auto Arg = S.Stk.pop<unsigned int>();
auto Result = __builtin_clz(Arg);
S.Stk.push<int>(Result);
return true;

This seems right enough to me, though you might consider CTZ as well since it is equally as easy. A better/more useful attempt is going to be builtin_strlen. Note that with builtins they are going to be particularly difficult because you can't execute them on the local machine, since we have to give the same result as the target machine. Integer sizes can be a problem for that, but a lot of the builtins work differently based on which target you're running on.

clang/lib/AST/Interp/ByteCodeExprGen.cpp
954

Whats happening here? Is this leftover debugging code?

This seems right enough to me, though you might consider CTZ as well since it is equally as easy. A better/more useful attempt is going to be builtin_strlen. Note that with builtins they are going to be particularly difficult because you can't execute them on the local machine, since we have to give the same result as the target machine. Integer sizes can be a problem for that, but a lot of the builtins work differently based on which target you're running on.

Hmm, I see. Do you know of any existing tests in the clang code base that exercise those differences?

clang/lib/AST/Interp/ByteCodeExprGen.cpp
954

Oh, yep!

This seems right enough to me, though you might consider CTZ as well since it is equally as easy. A better/more useful attempt is going to be builtin_strlen. Note that with builtins they are going to be particularly difficult because you can't execute them on the local machine, since we have to give the same result as the target machine. Integer sizes can be a problem for that, but a lot of the builtins work differently based on which target you're running on.

Hmm, I see. Do you know of any existing tests in the clang code base that exercise those differences?

I don't really know all that well... I don't spend much time in target-specific builtins. I think there are a couple of the floating-point and AVX type builtins that have differences between ARM and x86 though?

This seems right enough to me, though you might consider CTZ as well since it is equally as easy. A better/more useful attempt is going to be builtin_strlen. Note that with builtins they are going to be particularly difficult because you can't execute them on the local machine, since we have to give the same result as the target machine. Integer sizes can be a problem for that, but a lot of the builtins work differently based on which target you're running on.

Hmm, I see. Do you know of any existing tests in the clang code base that exercise those differences?

I'm not certain on existing tests, but the kinds of things I'm thinking about are builtins around floating-point (where the host and the target may be using different floating-point semantics entirely), builtin classification functions may be sensitive to compiler options like whether we honor nans or not, security builtins like __builtin_add_overflow which may behave differently on host and target depending on the size of variable-width types like long or __builtin_strlen whose return type is size_t, etc.

tbaeder abandoned this revision.Oct 22 2022, 7:52 AM

Let's shelve this until later.