Skip to content

V
V8
Switch branch/tag
  1. 17 Jan, 2014 13 commits
  3. 16 Jan, 2014 17 commits
  5. 15 Jan, 2014 10 commits
    • palfia@homejinni.com's avatar
      MIPS: This is a preview of a first step towards unification of the hydrogen call machinery. · 185829c6
      palfia@homejinni.com authored 
      Port r18626 (d3368a4c)

Original commit message:
The change replaces CallNamed, CallKeyed, CallConstantFunction and CallKnownGlobal hydrogen instructions with two new instructions with a more lower level semantics:

1. CallJSFunction for direct calls of JSFunction objects (no
   argument adaptation)

2. CallWithDescriptor for calls of a given Code object according to
   the supplied calling convention.

Details:

CallJSFunction should be straightforward, the main difference from the
existing InvokeFunction instruction is the absence of argument adaptor
handling. (As a next step, we will replace InvokeFunction with an
equivalent hydrogen code.)

For CallWithDescriptor, the calling conventions are represented by a
tweaked version of CallStubInterfaceDescriptor. In addition to the
parameter-register mapping, we also define parameter-representation
mapping there. The CallWithDescriptor instruction has variable number of
parameters now - this required some simple tweaks in Lithium, which
assumed fixed number of arguments in some places.

The calling conventions used in the calls are initialized in the
CallDescriptors class (code-stubs.h, <arch>/code-stubs-<arch>.cc), and
they live in a new table in the Isolate class. I should say I am not
quite sure about Representation::Integer32() representation for some of
the params of ArgumentAdaptorCall - it is not clear to me wether the
params could not end up on the stack and thus confuse the GC.

The change also includes an earlier small change to argument adaptor
(https://codereview.chromium.org/98463007) that avoids passing a naked
pointer to the code entry as a parameter. I am sorry for packaging that
with an already biggish change.

Performance implications:

Locally, I see a small regression (.2% or so). It is hard to say where
exactly it comes from, but I do see inefficient call sequences to the
adaptor trampoline. For example:

;;; <@78,#24> constant-t
bf85aa515a     mov edi,0x5a51aa85          ;; debug: position 29
;;; <@72,#53> load-named-field
8b7717         mov esi,[edi+0x17]          ;; debug: position 195
;;; <@80,#51> constant-s
b902000000     mov ecx,0x2                 ;; debug: position 195
;;; <@81,#51> gap
894df0         mov [ebp+0xf0],ecx
;;; <@82,#103> constant-i
bb01000000     mov ebx,0x1
;;; <@84,#102> constant-i
b902000000     mov ecx,0x2
;;; <@85,#102> gap
89d8           mov eax,ebx
89cb           mov ebx,ecx
8b4df0         mov ecx,[ebp+0xf0]
;;; <@86,#58> call-with-descriptor
e8ef57fcff     call ArgumentsAdaptorTrampoline  (0x2d80e6e0)    ;; code: BUILTIN

Note the silly handling of ecx; the hydrogen for this code is:

0 4 s27 Constant 1  range:1_1 <|@
0 3 t30 Constant 0x5bc1aa85 <JS Function xyz (SharedFunctionInfo 0x5bc1a919)> type:object <|@
0 1 t36 LoadNamedField t30.[in-object]@24 <|@
0 1 t38 Constant 0x2300e6a1 <Code> <|@
0 1 i102 Constant 2  range:2_2 <|@
0 1 i103 Constant 1  range:1_1 <|@
0 2 t41 CallWithDescriptor t38 t30 t36 s27 i103 i102 #2 changes[*] <|@

BUG=
R=plind44@gmail.com

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18630 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      185829c6
    • jarin@chromium.org's avatar
      Fix Win32 buildbreak (caused by overriden methods that have disappeared · 33b3f563
      jarin@chromium.org authored 
      while having the patch out for code review).

R=danno@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18627 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      33b3f563
    • jarin@chromium.org's avatar
      This is a preview of a first step towards unification of the hydrogen · 19d83271
      jarin@chromium.org authored 
      call machinery.  The change replaces CallNamed, CallKeyed,
CallConstantFunction and CallKnownGlobal hydrogen instructions with two
new instructions with a more lower level semantics:

1. CallJSFunction for direct calls of JSFunction objects (no
   argument adaptation)

2. CallWithDescriptor for calls of a given Code object according to
   the supplied calling convention.

Details:

CallJSFunction should be straightforward, the main difference from the
existing InvokeFunction instruction is the absence of argument adaptor
handling. (As a next step, we will replace InvokeFunction with an
equivalent hydrogen code.)

For CallWithDescriptor, the calling conventions are represented by a
tweaked version of CallStubInterfaceDescriptor. In addition to the
parameter-register mapping, we also define parameter-representation
mapping there. The CallWithDescriptor instruction has variable number of
parameters now - this required some simple tweaks in Lithium, which
assumed fixed number of arguments in some places.

The calling conventions used in the calls are initialized in the
CallDescriptors class (code-stubs.h, <arch>/code-stubs-<arch>.cc), and
they live in a new table in the Isolate class. I should say I am not
quite sure about Representation::Integer32() representation for some of
the params of ArgumentAdaptorCall - it is not clear to me wether the
params could not end up on the stack and thus confuse the GC.

The change also includes an earlier small change to argument adaptor
(https://codereview.chromium.org/98463007) that avoids passing a naked
pointer to the code entry as a parameter. I am sorry for packaging that
with an already biggish change.

Performance implications:

Locally, I see a small regression (.2% or so). It is hard to say where
exactly it comes from, but I do see inefficient call sequences to the
adaptor trampoline. For example:

;;; <@78,#24> constant-t
bf85aa515a     mov edi,0x5a51aa85          ;; debug: position 29
;;; <@72,#53> load-named-field
8b7717         mov esi,[edi+0x17]          ;; debug: position 195
;;; <@80,#51> constant-s
b902000000     mov ecx,0x2                 ;; debug: position 195
;;; <@81,#51> gap
894df0         mov [ebp+0xf0],ecx
;;; <@82,#103> constant-i
bb01000000     mov ebx,0x1
;;; <@84,#102> constant-i
b902000000     mov ecx,0x2
;;; <@85,#102> gap
89d8           mov eax,ebx
89cb           mov ebx,ecx
8b4df0         mov ecx,[ebp+0xf0]
;;; <@86,#58> call-with-descriptor
e8ef57fcff     call ArgumentsAdaptorTrampoline  (0x2d80e6e0)    ;; code: BUILTIN

Note the silly handling of ecx; the hydrogen for this code is:

0 4 s27 Constant 1  range:1_1 <|@
0 3 t30 Constant 0x5bc1aa85 <JS Function xyz (SharedFunctionInfo 0x5bc1a919)> type:object <|@
0 1 t36 LoadNamedField t30.[in-object]@24 <|@
0 1 t38 Constant 0x2300e6a1 <Code> <|@
0 1 i102 Constant 2  range:2_2 <|@
0 1 i103 Constant 1  range:1_1 <|@
0 2 t41 CallWithDescriptor t38 t30 t36 s27 i103 i102 #2 changes[*] <|@

BUG=
R=verwaest@chromium.org, danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18626 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      19d83271
    • jochen@chromium.org's avatar
      Revert of Make it possible to compile d8 for the host toolset as well... · c4530475
      jochen@chromium.org authored 
      Revert of Make it possible to compile d8 for the host toolset as well (https://codereview.chromium.org/139493002/)

Reason for revert:
still doesn't work on arm

Original issue's description:
> Make it possible to compile d8 for the host toolset as well
>
> 2nd attempt. Use a different output path for the host d8.
>
> BUG=v8:1775
> R=machenbach@chromium.org
> LOG=n
>
> Committed: https://code.google.com/p/v8/source/detail?r=18621

R=machenbach@chromium.org
TBR=machenbach@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:1775

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18623 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c4530475
    • machenbach@chromium.org's avatar
      Add tree control feature to auto-roll script. · 0684eb14
      machenbach@chromium.org authored 
      This CL enables the auto-roll script to close and reopen the tree when pushing.

Modifies an auto-roll test so that the push-to-trunk part is executed in order to test the new tree control feature.

BUG=
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      0684eb14
    • jochen@chromium.org's avatar
      Make it possible to compile d8 for the host toolset as well · d7f3fcf2
      jochen@chromium.org authored 
      2nd attempt. Use a different output path for the host d8.

BUG=v8:1775
R=machenbach@chromium.org
LOG=n

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18621 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d7f3fcf2
    • machenbach@chromium.org's avatar
      Revert "Make it possible to compile d8 for the host toolset as well" and "For... · bb372d9e
      machenbach@chromium.org authored 
      Revert "Make it possible to compile d8 for the host toolset as well" and "For V8, only build d8 on target"

This reverts commits r18618 and r18619 for breaking arm compilation.

BUG=
TBR=jochen@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18620 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      bb372d9e
    • jochen@chromium.org's avatar
      For V8, only build d8 on target · 95ab47fa
      jochen@chromium.org authored 
      BUG=none
TBR=machenbach@chromium.org
LOG=n

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      95ab47fa
    • jochen@chromium.org's avatar
      Make it possible to compile d8 for the host toolset as well · f6c7078d
      jochen@chromium.org authored 
      BUG=v8:1775
R=jkummerow@chromium.org
LOG=y

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18618 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f6c7078d
    • ulan@chromium.org's avatar
      Make cells pointing to JSObjects weak in optimized code. · 2638dca4
      ulan@chromium.org authored 
      This is done similar to weak embedded objects in optimized code (r17102). The
reference from optimized code to a cell is treated weakly in marking visitors
if the cell points to a JSObject. After marking we iterate over all cells
embedded in optimized code. If a cell is not marked but its value is marked,
then we revive the cell by marking it. Otherwise, the cell value is dead, so
we mark the code for deoptimization.

BUG=v8:2073
TEST=cctest/test-heap/CellsInOptimizedCodeAreWeak
LOG=Y
R=hpayer@chromium.org, mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      2638dca4