01:45 FROGGS joined 02:44 btyler joined
nwc10 jnthn: not broken. Try harder. 06:24
FROGGS "stout-enhanced"?? 07:24
*shudder*
07:38 brrt joined 08:16 vendethiel joined 10:08 vendethiel joined
jnthn o/ 10:14
nebuchadnezzar yo 10:15
FROGGS o/ 10:30
brrt \o 10:34
timotimo o_ 10:35
brrt &lunch; reading site.iugaza.edu.ps/hzaq/files/2010/...mming,.pdf which is interesting 10:36
10:57 FROGGS[mobile] joined
dalek arVM/inline: 21b669e | jnthn++ | src/spesh/inline.c:
Simple type-matching case of return -> goto.
 11:31
arVM/inline: 16214b3 | jnthn++ | src/spesh/inline.c:
Handle auto-boxing returns in inline.
 12:04
12:27 brrt joined
jnthn brrt: How're things going? :) 12:41
brrt hey, well, to be totally honest, i'm kind of stuck on the 'ponder the form of the jit graph' phase 12:42
jnthn ah 12:43
Well, if pondering isn't producing a way forward, implementing something that could possibly work and evolving it as you gradually need to make more things work might be a better direction. 12:44
brrt thats also a good idea, of course
FROGGS[mobile] that is what I usually do
jnthn Code doesn't lie. 12:45
brrt there are obviously quite a few technicalities that i can get working on that don't involve knowing the exact shape
jnthn Implementing an idea is often the fastest way to figure out if it's a good one or not, in my experience.
brrt true
i'm just feeling like i don't know enough yet 12:46
i guess thats my problem with a lot of projects - i try to figure out the hard things first, figuring the 'easy' stuff - i.e. stuff i understand - can come later 12:50
masak +1 on "working code trumps deep up-front thinking" 12:55
jnthn I think I'd just try to get an end-to-end small thing working (like, the add a couple of numbers of hello world one). 12:56
masak I fully endorse deep thinking, and I greatly enjoy it, but the quality deep thinking I get done is when I have some small running piece of code failing some core expectation.
jnthn Even if part of it is a throwaway, it will probably help get you over the hill, and be informative.
brrt ok, thats totally true in here, too :-) 12:57
its just, i can already /see/ the naive throwaway code fail ... 12:58
but i'm convinced
dalek arVM/inline: 004f5b0 | jnthn++ | src/spesh/dump.c:
Dump facts from inlinees also.
arVM/inline: 57b8bd0 | jnthn++ | src/spesh/candidate.c:
Ensure spesh log is flushed out to disk.

If we SEGV shortly after writing it, it's very valuable to have the full log.
brrt jnthn - its a reasonable assumption that a jit entry point will be given a MVMFrame, no? 13:44
jnthn brrt: Yes, or can always obtain it by being given a tc and doing tc->cur_frame
brrt hmmm 13:45
why, thats even simpler
although, perhaps its not
dalek arVM/inline: 7dec344 | jnthn++ | src/spesh/inline.c:
Merge fact counts table when merging the facts.
 13:47
arVM/inline: 6a0aba0 | jnthn++ | src/spesh/inline.c:
Add usage information to inline graph.

Otherwise, dead code elimination will go swallowing all the things.
13:52 vendethiel joined
dalek arVM/inline: 33f9d0a | jnthn++ | src/spesh/optimize. (2 files):
Collect arg-related instructions in call info.

This will make the available for the inliner to quickly access and tweak.		 13:57
arVM/inline: e23499f | jnthn++ | src/spesh/inline.c:
Re-write basic arg passing to set, invoke to goto.

With this, the inline transform for basic cases is now in place; main reason for things to not work out now is missing deopt updates.
14:10 zakharyas joined
brrt ok, now i know how to compile a relative address in dynasm 14:40
do we have an offsetof macro? 14:42
.. i don't think we do 14:43
we do have alignof
offsetof is defined in stddef.h 14:44
think its fair to include that?
timotimo i think i've used offsetof somewhere before 14:54
jnthn brrt: Seems reasonable.
timotimo and didn't include something more manually
maybe it's "already in there" on gcc? but then the windows build would have exploded
jnthn Yeah, I thought we mighta had it before... 14:55
brrt not in the current source :-)
jnthn Don't find a use of it in current source, though
brrt (ackoriding to ack)
timotimo oh
jnthn Anyway, that header and macro exists with MSVC too
timotimo i must have done that in a branch i later discarded or something
jnthn For many versions back
timotimo that must be the patch where i tried to build the specialized accessors for some repr or other 14:59
i think it was get_int and such, or something similar 15:00
brrt there are only two compilers and operating systems :-p windows and posix
15:05 vendethiel joined 15:16 jnthn joined 15:23 cognominal__ joined
dalek arVM/inline: d4df6a0 | jnthn++ | src/ (5 files):
Sketch out inlines table.

Will track extents in the bytecode where we have inlined code from another frame.		 15:37
arVM/moar-jit: 7e8418b | (Bart Wiegmans)++ | src/jit/ (3 files):
Compile jit entry/exit stuff so we don't forget our frame
 15:52
arVM/moar-jit: ad88672 | (Bart Wiegmans)++ | src/ (3 files):
Allocate the rbx register for the MVM register base.
arVM/moar-jit: 50bc894 | (Bart Wiegmans)++ | src/ (7 files):
Prototype emitting a C call. We can't represent addresses / values very well yet, so we don't add arguments.
jnthn wow! 15:53
jnthn goes to read :) 15:54
brrt appreciates comments and critique
15:55 cognominal joined
jnthn | sub rsp, 16 15:59
That 16 shows up quite a bit, I might prefer to give it a name :)
+ | mov [rsp-8], rdi // thread context
yay, that's a nice way to comment what things are :)
(Make it much easier to follow) 16:00
brrt had the same idea, will change it
jnthn Only other thing is meta: it's nice if your commit messages followed the usual git commit message formatting rules. 16:01
(Subject line, empty line, body if there's more to describe)
(Where subject line is up to 50 chars) 16:02
brrt ok, will do
i'd like a better name for MVMJitCCall, though 16:03
MVMJitCFunctionCall MVMJitNativeCall MVMJitCallNative
MVMJitCallC
jnthn Well, keeping it relatively short is nice 16:05
MVMJitCallC works for me.
brrt more readable than MVMJitCCall too 16:09
:-)
do you have an opinion wrt to the management of the stack pointer? i.e. change it on entry or change it on function call (as i do now) 16:16
the difference is in how you address stack values, by the way :-) 16:17
jnthn Would changing it on entry/exit not generally be cheaper, as we typically make multiple function calls? 16:18
brrt yes, i think it would 16:19
i'm going to check what gcc does
masak jnthn++ # now asking others to follow git commit message guidelines
jnthn It's kinda annoying to have to think of a 50-line description always. But it's kinda worth it for getting nice output from the tools. 16:20
OK, I really need to eat before I finish up this inline table calc. 16:21
shop &
masak I guess it qualifies as constrained writing. 16:23
the thing about constrained writing is that yes, it's a bit arbitrary, but it also tends to bring out nice results, mainly because the limitations force a bit of extra thought in a smaller/simpler state space.
brrt can't really write without constraints at all 16:27
clang subtracts from rsp on entry and refers to rbp instead 16:29
i guess that works, too
brrt finds intel syntax confusing 16:32
&dinne 16:34
dinner
16:59 nebuchadnezzar joined 17:02 brrt joined
nwc10 jnthn: *still* not broken. use more 'stout'? Maybe try absinthe? 17:16
vendethiel oooh, JIT work ! 17:18
brrt++ 17:19
17:24 colomon joined, woosley joined 17:25 synopsebot joined
dalek arVM/inline: 1b76d2a | masak++ | src/spesh/inline.c:
comment nitpick
 17:36
jnthn so nitpick :P 17:38
nwc10: Well, the reason you don't see all the breakage is that the inline stuff isn't actually turned on yet...I've got a local change here that does that. 17:39
nwc10 oh. "ho ho ho"? 17:41
masak .oO( Christmas comes early this year... if you have a local change ) 17:44
dalek arVM/inline: 7c41d88 | jnthn++ | src/spesh/graph.h:
Add spesh annotation for inline start/end.
 18:29
arVM/inline: 42fee86 | jnthn++ | src/spesh/dump.c:
Dumping of new inline start/end annotations.
arVM/inline: 54d3380 | jnthn++ | src/spesh/ (3 files):
Start building inline extents table.

Copes with inlining things that also had things inlined into them already.		 18:30
18:32 brrt joined 19:25 vendethiel joined
dalek arVM/inline: 61aa4f7 | jnthn++ | src/spesh/ (6 files):
Correctly form a deopt table for inlined code.

Also detect the inline case in deopt_one and deopt_all; for now it just throws.		 19:38
19:46 zakharyas joined
timotimo ooooh, sounds like we're getting pretty close 19:59
jnthn++ :)
except for a bit of cheerleading i've been super useless this week :S
jnthn Well, in theory this means we have the various data tables in place to re-create the frames...
timotimo just have to do it now :) 20:00
jnthn "just" :P 20:01
timotimo yeah, SMOP and stuff 20:02
nwc10 jnthn: *still* not broken 20:20
jnthn Phew :) 20:22
timotimo i thought that's because you have to explicitly turn it on? :) 20:23
jnthn Well, yeah, but collateral damage is also possible.
It's entirely possible the changes I'm doing could accidentally break spesh in the non-inline case. 20:24
If I were to miss something.
timotimo ah, sure
20:25 btyler joined
dalek arVM/inline: a19b0aa | jnthn++ | src/core/frame. (2 files):
Add a way to create a frame as part of uninlining.
 20:41
timotimo uninlining ... outlining? 20:42
jnthn: apart from multiplication and division into bit shifts, what cool strength reductions are commonly done? 20:43
turn adding 0 and multiplying 1 into sets? :) 20:44
jnthn Well, yeah... But SR beyond those transforms really involves looking at loops... 20:48
timotimo ah, i suppose that makes sense 20:49
how hard is common subexpression extraction in spesh?
easior or harder than loop invariant hoisting? :P 20:50
i think both are probably too hard for me at this point (and in the forseeable future :P)
jnthn timotimo: Given we're already in SSA form, you may find en.wikipedia.org/wiki/Global_value_numbering easier to get into 20:58
timotimo jnthn: wow, that article doesn't explain how that thing is done at all 21:19
"a good algorithm will give this perfect mapping. using that info, the redundant computations can then be removed" 21:21
well, gee ...
dalek arVM/inline: 46cce5f | jnthn++ | src/spesh/inline. (2 files):
Record inline result reg/type for use in deopt.
 21:22
jnthn timotimo: haha... :)
timotimo: Yeah, the article on SSA is just like that too :) 21:23
timotimo: It may reference some useful papers.
timotimo i've got some pdfs in front of me now
ah, well, that would have been very helpful to point out: these numberings are done by first pretending all nodes of the same type (operand/operator) are congruent and then partitioning noncongruent nodes later on 21:27
heh. an example that was run on an IBM RS/6000 Model 540 21:30
"running at 30mhz, with a 64 kb data cache" 21:31
jnthn Old paper is old :) 21:45
Doesn't mean it's bad, though. The algorithm is still probably as good as it was :) 21:46
dalek arVM/inline: b4d3b0b | jnthn++ | src/spesh/deopt.c:
Initial attempt at one-level uninline.

Structured to do multi-level, but that piece is not implemented just yet.		 21:49
timotimo of course
jnthn Tricky thing is tricky :) 21:51
Enough on that for today, I think :) 21:53
timotimo i'll wait with the weekly until i can run some benchmarks with inlining vs without inlining :) 21:56
jnthn Oh, I think I've 2-3 more days (well, evenings...) of work on this before we're at that point... 21:57
It's gonna need some debugging and I know there's some things left to do that it'll run into pretty rapidly. 21:58
timotimo d'aawc 22:03
jnthn Patience...or patches :P 22:15
'night o/
timotimo patchience 22:19

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!