Remove the last remnants of the TranscendentalCache.

Remove the last remnants of the TranscendentalCache.

It was only used for Math.log, and even then only in full code and in %_MathLog. For crankshafted code, Intel already used the FP operations directly, while the ARM/MIPS ports were a bit lazy and simply called the stub. The latter directly call the C library now without any cache. It would be possible to directly generate machine code if somebody has the time, from what I've seen out in the wild it should be only about a dozen instructions.

LOG=y
R=yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=18344

[Sven Panne, 2013-12-12 16:23:19]

LCodeGen::DoMathLog for ARM/MIPS still missing, will do at least the ARM part
soon. Waiting for performance numbers, too...

[Yang, 2013-12-13 13:35:38]

Looking good.

https://codereview.chromium.org/113343003/diff/1/src/arm/full-codegen-arm.cc
File src/arm/full-codegen-arm.cc (right):

https://codereview.chromium.org/113343003/diff/1/src/arm/full-codegen-arm.cc#...
src/arm/full-codegen-arm.cc:3705: __ CallRuntime(Runtime::kMath_log, 1);
We could directly call %Math_log from math.js and get rid of %_Math_log. Then
again, that would mean that if Math.log is optimized by itself and not inlined
into its caller, it would be very slow.

https://codereview.chromium.org/113343003/diff/1/src/serialize.cc
File src/serialize.cc (right):

https://codereview.chromium.org/113343003/diff/1/src/serialize.cc#newcode434
src/serialize.cc:434: 31,
Do we want to change the numbers here now that 30 has been removed?

[Sven Panne, 2013-12-13 13:55:10]

Platform ports done, PTAL again.

Adding our ARM/MIPS experts, please have a look that I didn't mess up register
constraints and/or calling conventions. :-}

[Sven Panne, 2013-12-13 13:59:49]

https://codereview.chromium.org/113343003/diff/1/src/arm/full-codegen-arm.cc
File src/arm/full-codegen-arm.cc (right):

https://codereview.chromium.org/113343003/diff/1/src/arm/full-codegen-arm.cc#...
src/arm/full-codegen-arm.cc:3705: __ CallRuntime(Runtime::kMath_log, 1);
On 2013/12/13 13:35:39, Yang wrote:
> We could directly call %Math_log from math.js and get rid of %_Math_log. Then
> again, that would mean that if Math.log is optimized by itself and not inlined
> into its caller, it would be very slow.

I came to the same conclusion (could be slow), furthermore sqrt is handled
similarly, so just changing this would be inconsistent. In a nutshell: I think
it is OK as it is in the CL, perhaps we might want to reconsider the whole
%_MathFoo story, but in a different CL.

https://codereview.chromium.org/113343003/diff/1/src/serialize.cc
File src/serialize.cc (right):

https://codereview.chromium.org/113343003/diff/1/src/serialize.cc#newcode434
src/serialize.cc:434: 31,
On 2013/12/13 13:35:39, Yang wrote:
> Do we want to change the numbers here now that 30 has been removed?

I think there is no need to do so. Furthermore, I'd like to clean up things here
a bit that no silly manual numbering is needed, but not in this CL.

[Yang, 2013-12-13 15:54:39]

LGTM if comments are addressed.

https://codereview.chromium.org/113343003/diff/40001/src/arm/lithium-codegen-...
File src/arm/lithium-codegen-arm.cc (right):

https://codereview.chromium.org/113343003/diff/40001/src/arm/lithium-codegen-...
src/arm/lithium-codegen-arm.cc:3939: __
CallCFunction(ExternalReference::math_log_double_function(isolate()),
I just took a look at ExternalReference::math_log_double_function.

It refers to math_log_double whose only purpose is to wrap log, which has the
same function signature. Are we sure the C++ compiler will inline this? Could
this external reference directly refer to log?

https://codereview.chromium.org/113343003/diff/40001/src/mips/lithium-mips.cc
File src/mips/lithium-mips.cc (right):

https://codereview.chromium.org/113343003/diff/40001/src/mips/lithium-mips.cc...
src/mips/lithium-mips.cc:1204: LOperand* input = UseRegister(instr->value());
We are not using a fixed double register anymore. Do we then get a double
register assigned?

[Sven Panne, 2013-12-16 08:20:22]

Feedback addressed, killing some dead ExternalReference stuff on the way.
Waiting for the tree to become green again after weeks of lemonish light... :-P

https://codereview.chromium.org/113343003/diff/40001/src/arm/lithium-codegen-...
File src/arm/lithium-codegen-arm.cc (right):

https://codereview.chromium.org/113343003/diff/40001/src/arm/lithium-codegen-...
src/arm/lithium-codegen-arm.cc:3939: __
CallCFunction(ExternalReference::math_log_double_function(isolate()),
On 2013/12/13 15:54:39, Yang wrote:
> I just took a look at ExternalReference::math_log_double_function.
> 
> It refers to math_log_double whose only purpose is to wrap log, which has the
> same function signature. Are we sure the C++ compiler will inline this? Could
> this external reference directly refer to log?

Good point. Of course the compiler won't "inline", because pointers have
identity, so redirecting directly to log would be wrong. I'm directly referring
to log now.

While we're there, we can kill most of double_fp_operation, too, only the MOD
case is ever used. Furthermore, compare_doubles is dead. I think we should
thoroughly review the code in this area, there seems to be a lot of dead code
lying around...

https://codereview.chromium.org/113343003/diff/40001/src/mips/lithium-mips.cc
File src/mips/lithium-mips.cc (right):

https://codereview.chromium.org/113343003/diff/40001/src/mips/lithium-mips.cc...
src/mips/lithium-mips.cc:1204: LOperand* input = UseRegister(instr->value());
On 2013/12/13 15:54:39, Yang wrote:
> We are not using a fixed double register anymore. Do we then get a double
> register assigned?

This seems to be the case, and it is done like this for floor, abs, sqrt, etc.

[Yang, 2013-12-16 08:41:25]

LGTM. One last remark.

https://codereview.chromium.org/113343003/diff/50001/src/assembler.cc
File src/assembler.cc (right):

https://codereview.chromium.org/113343003/diff/50001/src/assembler.cc#newcode...
src/assembler.cc:1524: FUNCTION_ADDR(mod_two_doubles),
Redirect to modulo directly? It's defined in platform.h.

[Sven Panne, 2013-12-16 09:52:34]

Feedback addressed. Net result of this CL: -1400 lines by now. >:-)

https://codereview.chromium.org/113343003/diff/50001/src/assembler.cc
File src/assembler.cc (right):

https://codereview.chromium.org/113343003/diff/50001/src/assembler.cc#newcode...
src/assembler.cc:1524: FUNCTION_ADDR(mod_two_doubles),
On 2013/12/16 08:41:26, Yang wrote:
> Redirect to modulo directly? It's defined in platform.h.

Done.

[m.m.capewell, 2013-12-16 11:44:54]

https://codereview.chromium.org/113343003/diff/70001/src/arm/lithium-arm.cc
File src/arm/lithium-arm.cc (right):

https://codereview.chromium.org/113343003/diff/70001/src/arm/lithium-arm.cc#n...
src/arm/lithium-arm.cc:1228: return DefineAsRegister(new(zone())
LMathLog(input));
Should this be MarkAsCall()? I can't see how caller-saved registers are
preserved across the call into the C library.

[Sven Panne, 2013-12-16 13:30:28]

https://codereview.chromium.org/113343003/diff/70001/src/arm/lithium-arm.cc
File src/arm/lithium-arm.cc (right):

https://codereview.chromium.org/113343003/diff/70001/src/arm/lithium-arm.cc#n...
src/arm/lithium-arm.cc:1228: return DefineAsRegister(new(zone())
LMathLog(input));
On 2013/12/16 11:44:54, m.m.capewell wrote:
> Should this be MarkAsCall()? I can't see how caller-saved registers are
> preserved across the call into the C library.

Good point, this problem is in the other platform ports, too. :-/ I'll upload a
new patch set with fixed DoMathLogs. It's a pity that MarkAsCall is more than is
actually needed, but we don't have a way to express "save caller-saved registers
across this". :-(

[Sven Panne, 2013-12-16 14:22:27]

Addressed feedback and made LChunkBuilder::DoMathLog more uniform across
platforms.

[m.m.capewell, 2013-12-16 14:24:52]

On 2013/12/16 14:22:27, Sven Panne wrote:
> Addressed feedback and made LChunkBuilder::DoMathLog more uniform across
> platforms.

I think you can either MarkAsCall() or stack/restore the registers manually in
lithium-codegen using ldm/stm and vldm/vstm, at least for the ARM backend.

[Sven Panne, 2013-12-17 07:00:51]

On 2013/12/16 14:24:52, m.m.capewell wrote:
> On 2013/12/16 14:22:27, Sven Panne wrote:
> > Addressed feedback and made LChunkBuilder::DoMathLog more uniform across
> > platforms.
> 
> I think you can either MarkAsCall() or stack/restore the registers manually in
> lithium-codegen using ldm/stm and vldm/vstm, at least for the ARM backend.

Of course one could do this manually, but this would mean that the platform ABI
logic is spread over the source code, which would be fundamentally wrong.
MarkAsCall will mark far more registers as used than is actually necessary if I
see things correctly. What we are missing in v8 is a simple and declarative
foreign function interface, e.g. in Haskell one can simply declare

   foreign import ccall "log" c_log :: CDouble -> CDouble

and simply use c_log as if it was written in Haskell, other languages have
similar features.

For our problem at hand, one should probably simply write an assembly version of
log for ARM and MIPS. This should be relatively easy using plain old math:

    log((1+ mantissa) * (2 ^ exponent))
  = log(1 + mantissa) + log(2 ^ exponent)
  = log(1 + mantissa) + exponent * log(2)

Extracting exponent and mantissa is easy given IEEE754, to calculate log in the
range [1..2) a few terms of the Taylor series (or some other approximation)
should suffice, log is very smooth. A quick Google search showed that this seems
to be the standard way of doing it, e.g.:

   http://www.netlib.org/fdlibm/e_log.c
   https://code.google.com/p/math-neon/source/browse/trunk/math_logf.c

[Sven Panne, 2013-12-18 10:40:53]

Committed patchset #8 manually as r18344 (presubmit successful).