Skip to content

V
V8
Switch branch/tag
  1. 20 Feb, 2014 1 commit
  3. 19 Feb, 2014 1 commit
  5. 18 Feb, 2014 1 commit
  7. 17 Feb, 2014 1 commit
  9. 13 Feb, 2014 1 commit
  11. 12 Feb, 2014 1 commit
  13. 30 Jan, 2014 1 commit
  15. 29 Jan, 2014 5 commits
  17. 28 Jan, 2014 1 commit
  19. 24 Jan, 2014 1 commit
  21. 17 Jan, 2014 1 commit
  23. 16 Jan, 2014 5 commits
  25. 15 Jan, 2014 2 commits
    • 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
  27. 14 Jan, 2014 1 commit
  29. 07 Jan, 2014 1 commit
    • jarin@chromium.org's avatar
      Fixed Lithium environment generation bug for captured objects (created · acf24331
      jarin@chromium.org authored 
      by escape analysis). Added several tests that expose the bug.

Summary:
LCodegen::AddToTranslation assumes that Lithium environments are
generated by depth-first traversal, but LChunkBuilder::CreateEnvironment
was generating them in breadth-first fashion. This fixes the
CreateEnvironment to traverse the captured objects depth-first.

Note:
It might be worth considering representing LEnvironment by a list
with the same order as the serialized translation representation
rather than having two lists with a subtle relationship between
them (and then serialize in a slightly different order again).

R=titzer@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18470 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      acf24331
  31. 18 Dec, 2013 1 commit
  33. 04 Dec, 2013 1 commit
  35. 02 Dec, 2013 1 commit
  37. 28 Nov, 2013 1 commit
  39. 22 Nov, 2013 1 commit
  41. 21 Nov, 2013 2 commits
  43. 19 Nov, 2013 1 commit
  45. 12 Nov, 2013 1 commit
  47. 08 Nov, 2013 1 commit
  49. 07 Nov, 2013 3 commits
  51. 06 Nov, 2013 1 commit
    • bmeurer@chromium.org's avatar
      Improve implementation of HSeqStringSetChar. · 980739a2
      bmeurer@chromium.org authored 
      This improves the generated code for HSeqStringSetChar across
all platforms, taking advantage of constant operands whenever
possible. It also drops the unused DefineSameAsFirst constraint
for the register allocator on x64 and ia32, where it caused
unnecessary spills when the string operand was live across the
HSeqStringSetChar instruction.

A new GVN flag StringChars is introduced to express dependencies
between HSeqStringSetChar, HStringCharCodeAt and the upcoming
HSeqStringGetChar (the GVNFlags type is now 64bit in size).

Also improves the test case.

TEST=mjsunit/string-natives
R=mstarzinger@chromium.org, yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17521 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      980739a2
  53. 31 Oct, 2013 1 commit
  55. 21 Oct, 2013 1 commit