• 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
macro-assembler-arm.cc 136 KB