[POSSIBLE PERFORMANCE IMPACT] Use __builtin_expect on Clang as well (for UNLIKELY and LIKELY)

[POSSIBLE PERFORMANCE IMPACT] Use __builtin_expect on Clang as well (for UNLIKELY and LIKELY)

OOPS:
Nop, since COMPILER(CLANG) => COMPILER(GCC)

Fixed gratuitous test in:
Remove redundant test: COMPILER(GCC) || COMPILER(CLANG) => COMPILER(GCC)
https://codereview.chromium.org/105673006/

====================================================
Original description

Performance impact:
Likely has minor positive effect on Mac (uses Clang).

UNLIKELY and LIKELY use __builtin_expect, which provides some performance
benefit (not a lot, but every bit helps).
This compiler directive is supported on Clang, not only GCC,
so this turns it on in Clang.
(This is the only use of __builtin_expect in Blink.)

(Suggested by Kouhei.)

Docs:
http://llvm.org/docs/BranchWeightMetadata.html#builtin-expect
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

[Nils Barth (inactive), 2013-12-13 02:37:22]

Hi Adam and Eric,
Kouhei recently observed that __builtin_expect is supported in Clang, not just
GCC.

The use in UNLIKELY and LIKELY seems to have some performance benefit, so this
CL adds it for Clang as well.

How does it sound?

[eseidel, 2013-12-13 03:06:10]

Fine by me, but this is really a C++ ninja (thakis/jyasskin) or perf-team
question.

I don't know if the linux bots use clang yet (they probably should, since then
they'd be closer to Mac which is a much larger market share).

[eseidel, 2013-12-13 03:06:31]

lgtm

[kouhei (in TOK), 2013-12-13 03:10:20]

lgtm

[haraken, 2013-12-13 03:12:12]

I don't think this is a right fix.

I think #if defined(GCC) implies #if defined(CLANG). So LIKELY/UNLIKELY should
be already enabled in clang as well.

For example, we can find '#if COMPILER(GCC) && !COMPILER(CLANG)' in Compiler.h.

(In that sense, "GCC" is a very confusing name.)

[haraken, 2013-12-13 03:12:42]

On 2013/12/13 03:12:12, haraken wrote:
> I don't think this is a right fix.
> 
> I think #if defined(GCC) implies #if defined(CLANG). So LIKELY/UNLIKELY should
> be already enabled in clang as well.
> 
> For example, we can find '#if COMPILER(GCC) && !COMPILER(CLANG)' in
Compiler.h.
> 
> (In that sense, "GCC" is a very confusing name.)

+thakis

[Nils Barth (inactive), 2013-12-13 03:41:45]

On 2013/12/13 03:12:12, haraken wrote:
> I don't think this is a right fix.
> 
> I think #if defined(GCC) implies #if defined(CLANG). So LIKELY/UNLIKELY should
> be already enabled in clang as well.
> 
> For example, we can find '#if COMPILER(GCC) && !COMPILER(CLANG)' in
Compiler.h.
> 
> (In that sense, "GCC" is a very confusing name.)

Yup, looks like GCC actually means "GNU C, or GCC-compatibility":
https://svn.boost.org/trac/boost/ticket/7473
http://rem.eifzilla.de/archives/2012/08/10/identify-theft-by-clang

There's also:
COMPILER(GCC) || COMPILER(CLANG)
...which should therefore be unnecessary.

[Nico, 2013-12-13 04:47:43]

not lgtm

COMPILER(GCC) is true for clang. this is a noop cl

[Nico, 2013-12-13 04:48:16]

Oh, haraken said that already. He's right :-)

[Nils Barth (inactive), 2013-12-13 04:57:56]

On 2013/12/13 04:47:43, Nico wrote:
> not lgtm
> 
> COMPILER(GCC) is true for clang. this is a noop cl

Got it, thanks!
There's thus a redundant test (hence why I was misled), removed in:
Remove redundant test: COMPILER(GCC) || COMPILER(CLANG) => COMPILER(GCC)
https://codereview.chromium.org/105673006/

[Chris Evans, 2013-12-13 06:29:13]

On 2013/12/13 04:47:43, Nico wrote:
> not lgtm
> 
> COMPILER(GCC) is true for clang. this is a noop cl

Hehe. A few months back, I made this mistake and also posted a no-op CL along
the same lines, also caught by Nico. ;-)