|
00:07
lizmat joined
03:46
FROGGS_ joined
07:05
zakharyas joined
07:17
Ven joined
07:23
Ven joined
07:24
brrt joined
|
|||
| brrt | \o | 07:25 | |
| .tell timotimo that a): the JIT (and the interpreter) both require alignment of basic blocks, moreso than having goto's in basic blocks | |||
| nwc10 | .tell brry that there appears to be no bot | ||
| er, | |||
| brrt | |||
| brrt | so that you could plausibly replace all gotos | ||
| oh | |||
| yes | |||
| shall i repeat on #perl6, or do you think he'll backog | 07:26 | ||
| nwc10 | I can't tell you for sure | ||
| brrt | well, just put it on #perl6 :-) | 07:29 | |
| where there are bots | |||
|
07:34
FROGGS joined
07:50
brrt joined
09:09
brrt joined
10:32
Ven joined
10:47
brrt left
11:29
brrt joined
12:00
Ven joined
12:51
lizmat joined
|
|||
| brrt | quiet today | 12:52 | |
| timotimo | i most usually backlog | 12:59 | |
| brrt | :-) | 13:00 | |
| although, yes, that's probably your issue, assigning to pred[num_pred] is an overflow :-) | 13:01 | ||
| timotimo | right; in the other code i saw it had a -- at the very beginning of the file where it was assigned to a variable | 13:08 | |
| brrt | also a null? | ||
|
13:09
zakharyas1 joined
|
|||
| timotimo | yeah | 13:30 | |
| brrt | ok, now that i actually have a decent internet connection | 13:32 | |
| i'm curious what you were / are trying to do with the union_goto branch | |||
| FROGGS | uff, just seen this in my bash: | 13:41 | |
| malloc: unknown:0: assertion botched | |||
| free: called with already freed block argument | |||
| brrt | in bash, or in moar? | 13:42 | |
| FROGGS | bash | 13:49 | |
| on a production server :S | 13:50 | ||
| brrt | oh, that doesn't surprise me | ||
| i've seen ssimilar behaviour from bash often enough :-) | |||
| FROGGS | that's the first time for me... | 13:57 | |
| and it scares me a little | |||
| brrt | do you have sufficient free memory? | 14:05 | |
| FROGGS | on the server yes | 14:06 | |
| but just recognized that my own hard disk was full... | |||
| brrt | some days :-) | 14:09 | |
| timotimo | well, i *thought* i could get the resulting jit code improved by reducing the overall number of gotos; especially in the jumplist case | 14:43 | |
| but since the jumplist implementation actually uses these BBs with only goto instructions for doing the jump, that's not useful at all | |||
| i would have to do some analysis to see how often we end up with blocks that jump to a block that only does another jump | |||
|
14:54
TimToady joined
|
|||
| brrt | i see | 14:57 | |
| any other place than jumplist, that's probably a good idea :-P | 14:58 | ||
| timotimo | only if it's worth much :) | 15:02 | |
| brrt | yeah, sure | ||
| brrt read the article about linear scan register allocation today | |||
| good news, it means register allocation can be done much simpler than with graph coloring, and the output will in all likelihood be very suitable | 15:03 | ||
|
15:05
TimToady joined
|
|||
| moritz | and what's the bad news? :-) | 15:05 | |
| brrt | second time somebody asks me that today, with the same answer | 15:08 | |
| there is no bad news | |||
| timotimo | poletto & sarkar? | 15:09 | |
| brrt | probably, yes | ||
| i had it from the luajit site | |||
| timotimo | www.cs.ucla.edu/~palsberg/course/cs...arscan.pdf - i have this one open right now | 15:10 | |
| brrt | either that, or one that looks very much like it, yes :-) | ||
| of course, the spill part of that algorithm spills to MVM memory 'registers', not to stack (in general) | 15:11 | ||
| timotimo | of course | ||
| brrt | in our case | 15:12 | |
| except when it doesn't, as in threadcontext and frame pointers | |||
| hmmm | |||
| :-) | |||
| timotimo | i hadn't considered the tc register to be spillable up until now | 15:17 | |
| brrt | well.... | 15:19 | |
| in the unlikely chance we never need it, it'd be a waste to keep it into a register forever | 15:20 | ||
| timotimo | yes | ||
| brrt | especially in a special callee-save register | ||
| although that will probably be the reality for a long time to come | |||
| timotimo | especially if we have tight numerical code the TC is likely not needed for almost all of the time | ||
| brrt | if possible it'd be nicest to keep it in rcx all the time and not do any moves for calling a c function | 15:21 | |
| but, i don't know yet | |||
| timotimo | how well does the algorithm cope with "and now we need to move these virtual registers into these exact real registers because we want to do a C call"? | 15:22 | |
| brrt | that's just a spill | 15:31 | |
| you implement the spilling yourself :-) | |||
| oh, no, i'm wrong | 15:32 | ||
| you mean the opposite | |||
| that's also just loading, and since you spill before doing a C call (as one must), that won't pose a problem either | 15:33 | ||
| but there's a reason i calculated time for doing a proof-of-concept | 15:34 | ||
| timotimo | right | 15:35 | |
| it's a good decision, IMO, to do a POC first | |||
| there's any number of screws one could adjust | |||
|
17:33
colomon joined
17:55
FROGGS joined
18:11
colomon joined
|
|||
| nwc10 | jnthn: from last night, not sure if irclog.perlgeek.de/moarvm/2015-05-17#i_10617824 is a bug (but suspect it is) and it might have performance implications (probably small) | 19:48 | |
|
20:37
japhb joined
20:54
japhb joined
23:02
vendethiel joined
23:23
LLamaRider joined
|
|||