I was wondering how to best implement builtin function calls, but I don't think actually generating bytecode for them makes much sense.
Details
Diff Detail
Event Timeline
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? |
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! |
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?
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.
Whats happening here? Is this leftover debugging code?