Store Eval::Info in Search::Stack

Instead of a pointer. This should fix the issue of
remaining with a stale pointer when for instance calling
IID, but also null search verification, singular search
and razoring where we call search with the same ss
pointer. In this case ss->ei is overwritten in the
search() call and upon returning remains stale.

This patch could have a performance hit because Eval::Info
is big (176 bytes) and during splitting we copy 4 ss entries.

On the good side, this patch is a clean solution.

Proposed by Gary.

No functional change.
Fix a crash introduced few days ago

Crash is due to uninitialized ss->futilityMoveCount that
when happens to be negative, yields to an out of range
access in futility_margin().

Bug is subtle because it shows itself only in SMP case.
Indeed in single thread mode we only use the

Stack ss[MAX_PLY_PLUS_2];

Allocated at the begin of id_loop() and due to pure
(bad) luck, it happens that for all the MAX_PLY_PLUS_2
elements, ss[i].futilityMoveCount >= 0

Note that the patch does not prevent futilityMoveCount
to be overwritten after, for instance singular search
or null verification, but to keep things readable and
because the effect is almost unmeasurable, we here
prefer a slightly incorrect but simpler patch.

bench: 4311634
Cache line aligned TT

Let TT clusters (16*4=64 bytes) to hold on a singe cache line.
This avoids the need for the double prefetch.

Original patches by Lucas and Jean-Francois that has also tested
on his AMD FX:

BIG HASHTABLE

./stockfish bench 1024 1 18 > /dev/null

Before:
1437642 nps
1426519 nps
1438493 nps

After:
1474482 nps
1476375 nps
1475877 nps

SMALL HASHTABLE

./stockfish bench 128 1 18 > /dev/null

Before:
1435207 nps
1435586 nps
1433741 nps

After:
1479143 nps
1471042 nps
1472286 nps

No functional change.
Fix a 'value > VALUE_INFINITE' assert

This fixes an assert while testing with debug on.

Assert was due to static null pruning returning value

eval - futility_margin(depth, (ss-1)->futilityMoveCount)

That was sometimes higher than VALUE_INFINITE triggering
an assert at the caller site.

Because eval con be equal to ttValue and anyhow is read from
TT that can be corrupted in SMP case, we need to sanity
check it before to use.

bench: 4176431
Temporary revert "Expose EvalInfo struct to search"

It is not needed for the release and introduces
a slowdown, although very small.

Probably it will be readded after the release.

No functional change.
Revert "Cache line aligned TT"

This reverts commit 083fe5812485597e13943b690cc24a8f25c0d140

It seems to break Android build

No functional change.
Stockfish 3

Stockfish bench signature is: 4176431
Restore development version

No functional change.
Tweak Mobility Area

Only consider pawns and the king as restricting.
Re-add "Cache line aligned TT"

But this time do not play with pointers, in
particular do not assume that size_t is an
unsigned type of the same width as pointers.

This code should be fully portable.

No functional change.
Another take at TT alignment

This time revert to original version but using
uintptr_t instead of size_t

Suggested by Lucas.

No functional change.
More aggressive move count pruning
Fix rounding issue
Merge mobility area tweak

A nice improvment.

Was good at 15+0.05
LLR: 2.96 (-2.94,2.94)
Total: 10731 W: 2176 L: 2040 D: 6515

And at 60"+0.05
LLR: 2.96 (-2.94,2.94)
Total: 10601 W: 1968 L: 1810 D: 6823

bench: 4676606
Print time and node count before search ends

This info is normally printed together with
PV info in uci_pv() but when search is stopped,
for instance when max search time is reached,
uci_pv is not called and we miss this bits.

Suggested by gravy_train

No functional change.
Drop some redundant defined(_WIN64)

When it is already defined(_WIN32).

According to Microsoft documentation:
http://msdn.microsoft.com/en-us/library/b0084kay.aspx

_WIN32 Defined for applications for Win32 and Win64. Always defined.

_WIN64 Defined for applications for Win64.

Patch suggested by Joona.

No functional change.
Merge some conditions

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Further simplify previous patch

No functional change.
Fix trapped rook condition

A rook is trapped if on rank 1 as is the king.
Currently the condition aloows for the rook
to be also in front of the pawns as long
as king is on first rank.

Verified with short TC test:
LLR: -1.71 (-2.94,2.94)
Total: 23234 W: 4317 L: 4317 D: 14600

Here what it counts is that after 23K games
result is equal.

bench: 4696542
Simplify previous condition

No functional change.