About __builtin_Functions.

Dhruv Matani dhruvbird@HotPOP.com
Mon Mar 15 17:25:00 GMT 2004


On Sun, 2004-03-14 at 23:14, Ian Lance Taylor wrote:
> Dhruv Matani <dhruvbird@HotPOP.com> writes:

> > > 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.

Ok, but what does the term "opencoded" mean in general when used in such
a context?

The closest I can guess is soemthing related to inlining.
Also, the documentation on this page: gcc/Keyword-Index.html links open
coding to inlining.

> 
> > > 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

Ok, thanks! This is really detailed stuff. As you said, I traced down
upto the i386.md file which uses the bsf{l} instruction in a very
complicated manner, which I could not comprehend, and will try to later.

> > 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.

Ok.

> > 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.

The particular definition of the macro I'm talking about is located in
the file: system.h

/* __builtin_expect(A, B) evaluates to A, but notifies the compiler that
   the most likely value of A is B.  This feature was added at some
point
   between 2.95 and 3.0.  Let's use 3.0 as the lower bound for now.  */
#if (GCC_VERSION < 3000)
#define __builtin_expect(a, b) (a)
#endif

But then again, this might be for older versions of the compiler that
didn't implement this optimization?

Thanks.






-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html




More information about the Libstdc++ mailing list