About __builtin_Functions.

[Ian Lance Taylor]

Dhruv Matani <dhruvbird@HotPOP.com> writes:

> So, __builtin_expect would be like an intrinsic, which is merely a hint
> for the compiler?

Yes.

> > Some intrinsics don't emit code, e.g., __builtin_constant_p.  Some can only
> > be open coded -- again, not the same thing as inlined -- under certain
> > circumstances, e.g., the math builtins, or the vector builtins.
> 
> Ok, but what exactly is open coded?

Are you looking for a specific answer about a specific builtin on a
specific target?  If so, ask that question.  It is impossible to
answer the question in general.  Some builtins have no associated
code.  Some builtins are always opencoded.  Some builtins are
opencoded under particular circumstances for particular targets.

> > My advice would be to pick a __builtin that's interesting to you and look
> > to see how it's implemented.  That will give you an idea of how they work.
> 
> Ok, I tried doing that for the one I'm interested in, which would be:
> __builtin_ctz, by greping through the whole gcc include directory, but
> couldn't find how it's implemented.
> Ok, I did find the bsfl instruction somewhere in the code, but the whole
> string __builtin_ctz, no... That's why I can't figure out:
> 
> 1. How it's implemented, and

__builtin_ctz can be found in builtins.def where it turns into
BUILT_IN_CTZ.  That can found in expand_builtin(), in builtins.c.
That calls expand_builtin_unop(), passing ctz_optab.  ctz_optab is
initialized in init_optabs(), in optabs.c, by calling
init_integral_libfuncs() with "ctz".  A further critical step of
initializing ctz_optabs appears in the file insn-opinit.c, which is
created based on the MD file (e.g., config/i386/i386.md) by the
genopinit program.  Essentially, if there is an insn named "ctzsi2" in
the MD file, it will become part of ctz_optabs for SImode.  For more
information on special insn names, see this part of the gcc internals
manual:
    http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard%20Names

> 2. Whether it will be inlined or not.

Well, if you followed all the above, you will see that __builtin_ctz
will be inlined if there is a "ctzM2" insn defined in the MD file for
an appropriate mode.

> I could compile with -S and check, but that would be too tedious for
> each and every builtin that I use, and I couldn't even confirm for every
> platform on which the code is compiled on.

Not only that, you would have to reconfirm it for every new gcc
release.

The question is: why do you care?  As long as __builtin_ctz will
return the correct result, who cares whether it is opencoded or not?

> I saw the compiled code, and it is being inlined on my platform
> x86-GNU/Linux. Will it hold for all platforms?

No.

> However I could find the macro __builtin_expect which is defined to be a
> macro translating to the first expression passed to it, and as you
> mentioned about it being an intrinsic, which does not generate any code
> so there is no question about inlining.

I don't know where you found that, but obviously gcc does not
implement __builtin_expect simply as a macro which returns its first
argument.

Ian