Skip to content

V
V8
Switch branch/tag
  1. 20 Aug, 2015 1 commit
  3. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored 
      Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.

In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.

The following changes were specifically	needed:

* Frame	has been changed to explicitly manage three areas of the
  callee frame, the fixed header, the spill slot area, and the
  callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
  a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
  to support the new stack slot indexing scheme. Crankshaft, which
  doesn't support the new slot numbering in its register allocator,
  must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
  to support saving only the optimal set of used registers, which is
  only known after register allocation is finished and spill slots
  have been allocated.

Review URL: https://codereview.chromium.org/1261923007

Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  5. 12 Aug, 2015 1 commit
  7. 03 Aug, 2015 2 commits
  9. 24 Jul, 2015 1 commit
  11. 23 Jul, 2015 1 commit
  13. 21 Jul, 2015 1 commit
  15. 17 Jul, 2015 1 commit
  17. 13 Jul, 2015 2 commits
  19. 10 Jul, 2015 1 commit
  21. 03 Jul, 2015 1 commit
  23. 02 Jul, 2015 1 commit
  25. 01 Jul, 2015 1 commit
    • danno's avatar
      Make context register implicit for CallInterfaceDescriptors · 7015fd20
      danno authored 
      Up until now the context register was listed explicitly in each stub's
CallInterfaceDescriptor. This was problematic, because it was listed
first in the list of register parameters--which is fine for Crankshaft,
which is more or less built to handle the context as the first
parameter-- but not ideal for TurboFan, which adds the context at
the end of all function parameters. Now the context register is no
longer in the register list and can be handled appropriately by both
compilers. Specifically, this allows the FunctionType specified for
each CallInterfaceDescriptor to exactly match the parameter register
list.

Review URL: https://codereview.chromium.org/1211333003

Cr-Commit-Position: refs/heads/master@{#29402}
      7015fd20
  27. 30 Jun, 2015 1 commit
  29. 25 Jun, 2015 1 commit
  31. 18 Jun, 2015 1 commit
  33. 15 Jun, 2015 1 commit
  35. 10 Jun, 2015 1 commit
  37. 09 Jun, 2015 2 commits
  39. 08 Jun, 2015 1 commit
    • jarin's avatar
      Unify decoding of deoptimization translations. · 9127d4ee
      jarin authored 
      This unifies methods Deoptimizer::DoTranslateCommand, Deotpimizer::DoTranslateObject and the arguments object materializer.

To unify these, we have to separate reading of the input frame from writing to the output frame because the argument materializer does not write to output frames.

Instead, we now deoptimize in following stages:

1. Read out the input frame/registers, decode them using the translations from the deoptimizer and store them in the deoptimizer (Deoptimizer::translated_state_). This is done in TranslatedState::Init.

2. Write out into the output frame buffer all the values that do not require allocation. We also remember references to the values that require materialization. As before, this is done in Deoptimizer::DoCompute*Frame method, but instead calling to DoTranslateCommand, we use the translated frame to obtain the values and write them to the output frames.

3. The platform specific code then sets up the output frames and calls into the deoptimization notification. This has not been changed at all.

4. Once the stack is setup, we handlify all the references in the saved translated values (TranslatedState::Prepare).

5. Finally, we materialize all the values we remembered in step (1) and write them to their frames on the stack (using the TranslatedValue::GetValue method).

BUG=

Review URL: https://codereview.chromium.org/1136223004

Cr-Commit-Position: refs/heads/master@{#28826}
      9127d4ee
  41. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

Review URL: https://codereview.chromium.org/1162993006

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  43. 03 Jun, 2015 1 commit
  45. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

Review URL: https://codereview.chromium.org/1131783003

Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  47. 01 Jun, 2015 1 commit
  49. 29 May, 2015 1 commit
  51. 28 May, 2015 1 commit
  53. 21 May, 2015 1 commit
  55. 12 May, 2015 1 commit
  57. 08 May, 2015 1 commit
    • mvstanton's avatar
      TurboFan: commit dependencies only on update of the opt. code list. · f9c46ed1
      mvstanton authored 
      TurboFan compilation was committing dependencies long before the
optimized function made it's way into the optimized code list for
the native context. The problem is that once the code pointer is out
there in dependency arrays, it is eligible for deopt. But the deopt
logic needs the code to be in the optimized code list to fully do it's
job.

BUG=
R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1136693003

Cr-Commit-Position: refs/heads/master@{#28312}
      f9c46ed1
  59. 04 May, 2015 1 commit
  61. 24 Apr, 2015 1 commit
  63. 23 Apr, 2015 1 commit
  65. 16 Apr, 2015 1 commit
  67. 15 Apr, 2015 1 commit
  69. 13 Apr, 2015 1 commit
    • vegorov's avatar
      Treat HArgumentsObject as a safe use during Uint32 analysis phase. · 021f7381
      vegorov authored 
      Deoptimization infrastructure already handles it correctly.

This change fixes repetitive deoptimizations in the code like this:

    var u32 = new Uint32Array(1);
    u32[0] = -1;

    function tr(x) { return x|0; }
    function ld() { return tr(u32[0]); }

    while (true) ld();

Currently inlined tr will contain HArgumentsObject that is considered uint32-unsafe use and prevents u32[0] from becoming uint32 load - instead a speculative int32 load is generated which just deopts.

BUG=

Review URL: https://codereview.chromium.org/1077113002

Cr-Commit-Position: refs/heads/master@{#27781}
      021f7381
  71. 09 Mar, 2015 1 commit
    • loislo's avatar
      CpuProfiler: fix for GetDeoptReason code. · 66ab309e
      loislo authored 
      The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.

We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.

The test was reworked so it tests identical functions against different reasons.

BUG=chromium:452067
LOG=n

Review URL: https://codereview.chromium.org/984773003

Cr-Commit-Position: refs/heads/master@{#27076}
      66ab309e
  73. 27 Feb, 2015 1 commit