| timotimo | i wonder why the sp_bind_* ops are NYI? do they require something more than just setting the value at an offset? | 00:13 | |
| like, do they have to ASSIGN_REFERENCE? | |||
| ASSIGN_REF, that is | |||
| on the other hand, having ASSIGN_REF doesn't stop us from having just the "target object, offset, value" op layout | 00:14 | ||
| huh? sp_get_o is NYI? but all the other sp_get_* ops aren't? | 00:17 | ||
| this must be purely on-demand implementation that i'm seeing nad not some deeper underlying difficulty that i may be missing | |||
| brrt, why does the emit*.dasc file grab the offset for a sp_p6obind_* via the .callsite_idx union member? | 01:16 | ||
| dalek | arVM/jit_throw_ops: a861e6f | timotimo++ | src/core/interp.c: implement the remaining sp_get_* and sp_bind_* ops in interp |
01:33 | |
| arVM/jit_throw_ops: b96924d | timotimo++ | src/jit/ (2 files): jit sp_bind_* ops |
|||
| arVM/jit_throw_ops: b1228a7 | timotimo++ | src/spesh/facts.c: learn about newexception's type facts |
|||
| arVM/jit_throw_ops: 5f10592 | timotimo++ | src/spesh/optimize.c: spesh newexception and bindex* into sp_fastcreate and sp_bind_* |
|||
|
02:09
vendethiel joined
03:49
vendethiel joined
07:15
vendethiel joined
09:00
brrt joined
|
|||
| brrt | timotimo: very simple answer to that. arg 2 to sp_(p6o_)?bind_[inso] is u16 | 09:02 | |
| lit_i16 is signed | |||
| hence, wrong | |||
| on the other hand, if you assign them as lit_i16 values.... | 09:03 | ||
| anyway | |||
| i'm going to check your patches out | |||
| on the other hand | 09:14 | ||
| it seems that i've been totally inconsistent with the u16/i16 distinciton | 09:15 | ||
| and i have a hard time finding a real case where it matters; for situations that are somewhat likely to overflow we typically use i32 anyway | |||
| dalek | arVM/jit_throw_ops: 3f9c337 | brrt++ | src/ (3 files): Remove logging Also remove superfluous stores and made use of i16 as an offset consistent. Wrong, but consistent. |
09:29 | |
|
09:50
cygx joined
|
|||
| cygx | o/ | 09:50 | |
| typo: github.com/MoarVM/MoarVM/search?ut...;type=Code | |||
| brrt | wow | 09:53 | |
|
09:53
vendethiel joined
|
|||
| brrt | that is a persistent typo | 09:53 | |
| cygx | I suspect there was some code completion involved | 09:54 | |
| timotimo | what's the story behind that typo? | 09:57 | |
| um | |||
| wat's de story behind dat typo? | |||
| brrt doesn't know | 09:58 | ||
| cygx | just something I noticed while looking at open pull requests, in particular github.com/MoarVM/MoarVM/pull/212/files | 09:59 | |
| brrt | hmm | 10:02 | |
| that looks sane to me | |||
| (the patch, i mean | |||
| timotimo | oh, wow, we've had pretty many pull requests so far | ||
| cygx | timotimo: you've got an open one for rakudo from 2013 | ||
| timotimo | uh oh :) | 10:03 | |
| the raw blocks thing | 10:04 | ||
| brrt | ehm, many of these pull requests look good | 10:06 | |
| i'll see if i can merge them after lunch | |||
| timotimo | cool | ||
| brrt | afk & | ||
| timotimo | i'm glad my patches look good to you :) | ||
| well, the jit throw ops ones | |||
| i'd really like to find out why &THROW-NIL doesn't get inlined into &next | 10:07 | ||
| maybe :throwish ops cause the inliner to immediately bail out? | |||
| but then, why isn't &next inlined into the frames of send-more-money-loops? | 10:08 | ||
|
10:15
FROGGS joined
|
|||
| cygx | btw, should MVM_exception_throw_adhoc() take a char** argument of strings to free? | 10:19 | |
| right now, MoarVM leaks C strings... | |||
| (as far as I can tell) | 10:20 | ||
| FROGGS | hmmmm, that's perhaps sane | ||
| it does, yes | |||
| cygx | so, who wants to go through the 886 occorrences of the term 'throw_adhoc' in MoarVM ;) | 10:31 | |
| timotimo | ideally, we'd have a second function that does the freeing thing | ||
| ooooh, inlining at the spesh level is prevented by having lexical access to any frame that refers to outers | 10:32 | ||
| so not having lexicals-to-locals working any more makes spesh inlining much weaker, too | |||
| hum. the specialization of THROW-NIL is finished before next's is | 10:36 | ||
| THROW-NIL contains no ops that'd prevent inlining | |||
| cygx | so instead of freeing the strings in MVM_exception_throw_adhoc_va(), do it after the longjmp() in MVM_interp_run() | 10:37 | |
| timotimo | the callsite for THROW-NIL's specialization matches the one prepared in next for the call ... | 10:40 | |
| hm. the spesh dump doesn't contain any information about guards the specialization relies upon; i could put that in | 10:41 | ||
| cygx | any ideas for a good name for the function that does an adhoc_throw and cleans p | 10:50 | |
| *clean up after intself? | 10:51 | ||
| *cleana | |||
| *cleans | |||
| timotimo | php.net/manual/de/function.mysql-r...string.php ā take inspiration from winners? :) | ||
| cygx | MVM_exception_throw_adhoc_tidy? MVM_exception_throw_adhoc_collect with a waste parameter? | 10:55 | |
| os just MVM_exception_throw_adhoc_free? | |||
| timotimo | MVM_exception_throw_adhoc_free and MVM_exception_throw_adhoc_premium :) | 10:56 | |
| do we have a clue how much we actually leak? | |||
| in a regular program run? or maybe "collected over the spec tests"? | 10:57 | ||
| my last resort seems to be littering the spesh code with stderr output to figure out what's going wrong ;( | 11:08 | ||
| cygx | preparing lunch & | 11:11 | |
| timotimo | gist.github.com/timo/104e64dc729f69987350 ... seriously? %) | 11:22 | |
| i don't understand why these getlexstatic_o aren't turned into spesh slot reads; these ops had logs put in for them, according to the spesh log | 11:30 | ||
| and i really don't expect the value they pointed to to have changed, except if they were in the young generation - for some strange reason - and got moved around since the last log ?! | 11:31 | ||
| dalek | arVM/jit_throw_ops: d51fd47 | timotimo++ | / (3 files): sp_log doesn't take a sslot, it's a "log slot", which is int16 |
11:36 | |
| arVM/jit_throw_ops: 1059847 | timotimo++ | src/spesh/dump.c: [speshdump] show argument guards directly below callsite |
11:37 | ||
| timotimo | '' (0x2e0a550): looking for inline candidates to 'next' | 11:47 | |
| '' (0x2e0a550): candidate number 0 is a good choice. | |||
| survived the simplest checks | |||
| found instruction getlex_no, which is no_inline. | |||
| '' (0x2e0a550): can't inline, boo :( | |||
| well ... :\ | |||
| getlex_no r0(5), lits(&EXHAUST) | 11:48 | ||
| bindlex lex(idx=5,outers=0,RETURN), r0(5) | |||
| god damn it | |||
| i don't think i really understand the whole exhaust, return, dispatcher, ... stuff thoroughly | |||
| all i know is that multi methods get it | 11:49 | ||
| since we're trying to inline that anyway, shouldn't we be able to throw (most of?) that stuff out? | 11:50 | ||
| timotimo considers putting in a dump of logged values | 12:01 | ||
|
12:50
cygx joined
|
|||
| cygx | sent github.com/MoarVM/MoarVM/pull/219 | 13:01 | |
| timotimo | ah, so a null-terminated list of pointers | 13:03 | |
| gist.github.com/timo/cec6c14aac3f8484eb12 ā yay or nay? | 13:10 | ||
| i'll probably also output some random info about the values in the explanation bellow | 13:11 | ||
| hm, the (-) looks a bit too "big"for a non-filled slot | |||
| i obviously don't understand printf formatting | 13:14 | ||
| why would "% 2d" have different lengths for 0-9 and 10-99? | 13:15 | ||
| apparently i need to use 3 if i want same-length outputs for those ranges | 13:16 | ||
| maybe it's meant to always put a space up front? | 13:17 | ||
| cygx | timotimo: the idea behind the space prefix is to make negative and non-negative nmbers the same length without adding a + | 13:19 | |
| timotimo | ah | 13:20 | |
| i hadn't realized that | |||
| so it leaves space for a -, but in my case i only have positive numbers and it never occurs that a - ends up there | 13:21 | ||
| cygx | that's it | ||
| timotimo | i did something terrible and built a tell_ds + rewind_ds function pair for the DumpStr object | ||
| and if the table contains only empty slots (like if the logging stuff has just been put in, but never run) i rewind the DumpStr | 13:22 | ||
| rather than checking the values up front | |||
| but dumping spesh isn't a performance-critical thing anyway | |||
| dalek | arVM/jit_throw_ops: 846cd07 | timotimo++ | src/spesh/dump.c: output number of spesh & log slots and a log table in spesh dump |
13:23 | |
| arVM/jit_throw_ops: 2ff5011 | timotimo++ | src/spesh/optimize.c: since spesh slots are immutable pointers, we can re-use them |
|||
| timotimo | oh, i committed log output again | 13:25 | |
| dalek | arVM/jit_throw_ops: d17f3a5 | timotimo++ | src/spesh/optimize.c: remove debug output |
||
|
14:34
Peter_R joined
|
|||
| timotimo | huh ... on my laptop builds and the benchmark i'm using are both broken ... ?! | 15:11 | |
| re-using spesh slots seems to cause that problem | 15:14 | ||
| there's places where we grab a spesh slot with the value set to NULL so that we can put values into them later, in that case re-use is definitely taboo | 15:19 | ||
| dalek | arVM/jit_throw_ops: 23f25e0 | timotimo++ | src/spesh/optimize.c: spesh slot reuse must be opted in, otherwise we crash |
15:24 | |
|
15:25
FROGGS joined
|
|||
| timotimo | gist.github.com/timo/1883a8c4287650f38925 - i wonder why these P6ints with the same value end up with different locations in memory | 15:53 | |
|
16:03
zakharyas joined
|
|||
| timotimo | where do we box an integer without hitting the cache?! | 16:24 | |
|
16:46
cygx joined
17:28
FROGGS joined
18:53
cygx left
|
|||
| timotimo | the next thing i'd love to have is to show the exact instruction that wrote the value that got logged next to the table | 19:05 | |
|
20:22
zakharyas joined
21:20
Peter_R joined
21:30
lizmat joined
|
|||
| timotimo | i think i know what's going on | 21:37 | |
| the int cache doesn't get marked | |||
| so it's quite possible that the int type it gets made for moves after the first GC? | |||
| i would have expected that type to land in gen2, though | |||
| making an intcache for 0x1c62338 | 21:40 | ||
| nursery's at 0x7fcfc57e0010 and 0x7fcfc53df010 right now | |||
| i suppose that answers it | |||
| but why, then, doesn't it register? :\ | 21:41 | ||
|
22:18
vendethiel joined
23:20
vendethiel joined
|
|||