About __builtin_Functions.

[Dhruv Matani]

On Mon, 2004-03-15 at 23:10, Ian Lance Taylor wrote:
> Dhruv Matani <dhruvbird@HotPOP.com> writes:
> 
> > > 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.
> 
> I suppose that open-coded is essentially equivalent to inlined.  The
> difference is that there is no actual function to be inlined.  For
> example, the multiplication operator may be open-coded, and usually
> is.  But on a machine which does not support hardware multiplication,
> the operator is handled as a call to the function __mulsi3.  It would
> be a little strange to say that the multiplication operator is
> normally inlined, so instead we say that it is normally open-coded.
> In general gcc will either open-code a builtin function, or it will
> generate a call to a function provided in libgcc.a.

Ok, I get the picture, so basically when we are talking about biultin
functions translating directly to some CPU instruction like the
builtin_ctz function, open-coded comes into the picture.

> 
> 
> > > > 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?
> 
> Correct.  That is there because the gcc code itself uses
> __builtin_expect, and it arranges to #define the macro when gcc itself
> is compiled with versions of gcc before __builtin_expect was defined.
> 
> The actual implementation of __builtin_expect can be found in
> expand_builtin_expect() in builtins.c.  That is fairly simple--it just
> emits a NOTE_INSN_EXPECTED_VALUE note.  A few other places in the
> compiler then check for that note, notably the branch prediction
> routines found in predict.c.

Ok.

Actually, I have just started reading about Compiler design from the
Dragon book, and the thing is that it really interests me, and I just
can't believe the complexity involved in creating a compiler, esp
something as huge as gcc, which not only supports so many platforms, but
also goes ahead and provides optimizations for each one of them! Phew!
That does take some doing!

Every time I look at the gcc code, the only thing I can say is "It's a
jungle out there!"



Thanks.






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

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