1) 0x36c28f53eecf    47  e8cc92fdff     call 0x36c28f5181a0     ;; code: 
contextual, LOAD_IC, GENERIC
Who does generate this stub? Full-codegen?

2) As I undertood the effictive code is placed in IC stub? If this is true 
then where can I see the stub's code?

On Tuesday, February 16, 2016 at 3:18:07 PM UTC+6, Jakob Kummerow wrote:
>
> On Tue, Feb 16, 2016 at 10:08 AM, <[email protected] <javascript:>> wrote:
>
>> Thank Jakob.
>>
>> Consider much more easier function:
>>
>>
>> function foo(o) {
>>  return o.x;
>> }
>>
>>
>> print(foo(37));
>>
>>
>> listing <http://pastebin.com/u0ZM8C3w>
>>
>> I've got two question:
>> 1) 0x36c28f53eecf    47  e8cc92fdff     call 0x36c28f5181a0     ;; code: 
>> contextual, LOAD_IC, GENERIC
>> Does that code create new IC stub? Where is the check for IC placed?
>>
>
> That's the call to the IC stub. The stub is created elsewhere 
> (dynamically, as needed). All the type checks happen inside the stub, not 
> in the enclosing function.
>  
>
>>
>> I believe that check should looks like:
>> if (actual_type1 == int) -> generate IC stub for int, if it exists then 
>> we call it
>> if (actual_type1 == double) ...
>>
>
> More like:
> if (hidden class of o == previously seen hidden class) { call previously 
> generated handler }
> else miss /* call into C++ to create a new handler for the new hidden 
> class */
>
> At least that's the standard "monomorphic" case. The IC system is quite 
> flexible, each IC can be in one of many different states.
>
>
>> 2) How to remove lines that looks like debug *. For example : debug: 
>> statement 19
>>
>
> They're just comments, part of the --code-comments output. Their purpose 
> is to make it easier for you to trace machine instructions back to the 
> JavaScript source.
>  
>
>> On Tuesday, February 16, 2016 at 2:31:58 PM UTC+6, Jakob Kummerow wrote:
>>>
>>> On Tue, Feb 16, 2016 at 8:10 AM, <[email protected]> wrote:
>>>
>>>> Thank Ben, but I need to some example:
>>>>
>>>> function add(a, b) {
>>>>  return a + b;
>>>> }
>>>>
>>>>
>>>> print(add(37, 73));
>>>> I execute this code via d8.
>>>>
>>>> What is context in that case?
>>>>
>>>
>>> Your function "add" is so simple that it doesn't need a context, and 
>>> indeed no context is allocated.
>>>  
>>>
>>>> I've got the asm listing via  --print-code: listing 
>>>> <http://pastebin.com/NhWyhRDK>
>>>> Actually I can't understand why the listing consists so many codes? The 
>>>> adder function is very simple.
>>>>
>>>> 0xda955b3eff6   150  49ba0000000025000000 REX.W movq r10,0x2500000000
>>>> 0xda955b3f000   160  4152           push r10
>>>> 0xda955b3f002   162  49ba0000000049000000 REX.W movq r10,0x4900000000
>>>> 0xda955b3f00c   172  4152           push r10
>>>> 0xda955b3f00e   174  48ba0000000007000000 REX.W movq rdx,0x700000000
>>>> 0xda955b3f018   184  488b7c2418     REX.W movq rdi,[rsp+0x18]
>>>> 0xda955b3f01d   189  e85efcffff     call 0xda955b3ec80       ;; code: 
>>>> CALL_IC, GENERIC
>>>> 0xda955b3f022   194  488b75f8       REX.W movq rsi,[rbp-0x8]
>>>> 0xda955b3f026   198  48890424       REX.W movq [rsp],rax
>>>>
>>>>
>>> ^ That's the compiled top-level code. The compiled code for function 
>>> "add" is in lines 109 - 170 in your pastebin. You can tell either by 
>>> looking at the "--- Raw source ---" section, or at the "name = add" line.
>>>
>>> If you run with --code-comments, you'll get comments embedded into the 
>>> code that'll explain what each section was generated for.
>>>
>>>
>>>> On Monday, February 15, 2016 at 11:14:58 PM UTC+6, Ben Noordhuis wrote:
>>>>
>>>>> On Mon, Feb 15, 2016 at 1:57 PM,  <[email protected]> wrote: 
>>>>> > Hi all! 
>>>>> > 
>>>>> > I'm trying to understand the full-codegen compiler in v8. 
>>>>> > 
>>>>> > Ok, I've taken the full-codegen code for x64 architecture. 
>>>>> > 
>>>>> > As I can see in code, it does following things: 
>>>>> > Build x64 frame 
>>>>> > Allocate locals 
>>>>> > And then allocate context <- this is magic for me 
>>>>> > 
>>>>> > The code's: 
>>>>> > 
>>>>> > // Possibly allocate a local context. 
>>>>> > 
>>>>> >   if (info->scope()->num_heap_slots() > 0) { 
>>>>> > 
>>>>> >     Comment cmnt(masm_, "[ Allocate context"); 
>>>>> > 
>>>>> >     bool need_write_barrier = true; 
>>>>> > 
>>>>> >     int slots = info->scope()->num_heap_slots() - 
>>>>> > Context::MIN_CONTEXT_SLOTS; 
>>>>> > 
>>>>> >     // Argument to NewContext is the function, which is still in 
>>>>> rdi. 
>>>>> > 
>>>>> > ... 
>>>>> > 
>>>>> > 
>>>>> > What does the full-codegen does here? 
>>>>>
>>>>> The context it allocates is the storage for a function's free 
>>>>> variables.  V8's garbage collector is generational; the write barrier 
>>>>> is for tracking object references from the old space to the new space. 
>>>>>
>>>> -- 
>>>>
>>>

-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to