In glibc in file strcmp I see a definition of strcmp function and below it there is a macro "libc_hidden_builtin_def (strcmp)".
This macro "libc_hidden_builtin_def (strcmp)" looks to be defining some platform(x32-64, i386) specific implementation of strcmp.
Question is when is this libc_hidden_builtin_def (strcmp) gets enabled, called and used?
It's not a real function. g++ and many other compilers will inline these functions -- add a few instructions in the program itself, rather than doing an entire branch/return for a function. Since a branch/return may be as time-consuming as the comparison itself for such a simple thing as strcmp, this saves a lot of performance.
Some CPUs come pretty close to providing libc funtions, so a call and stack pushes are an undesirable overhead, while others need considerable code to do it, which can be had as a call, or optionally as an inlined function, depending on the compiler directives and options. If you strcmp once a day, why not do the call? If it is in an inner loop, inlining opens it up to scheduling compilers that rearrange the pieces for optimal CPU internal exploitation, like for CPUs with multiple parallel integer units calculating addresses and data.
And even CPU's which don't have direct support, may have less overhead for a small sequence of instructions than a function call.
Thanks Corona and DGPicket for the reply.
That clears my doubt.
You gotta have it for compilations where it was not inlined. But branches and calls do mess up the instruction buffering and scheduling compiler efforts, very much like a seek flushing i/o buffers.
Ok thanks dgpickett.
Actually my call to getopt_long() is crashing in __strncmp_sse2 and so I had raised this post.
I will debug the inputs of getopt_long.
I anticipate that the passing of a properly constructed array of short and long option names and types and such leaves room for error.