github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
ItchyPlant Hello 07:41
Some hours ago the MoarVM/NQP/Rakudo 2018.11 packages were released, which is great, and I'd like to try them too on AIX 7.2.
While 2018.10 could be compiled the same way as I succeded with 2018.09, now this new one fails at MoarVM part: 07:42
gist.github.com/ItchyPlant/114c0ca...17906ccafb
make[1]: *** No rule to make target 'atomic_ops/sysdeps/loadstore/acquire_release_volatile.template', needed by 'atomic_ops/sysdeps/loadstore/acquire_release_volatile.h'. Stop. 07:43
samcv hey ItchyPlant 07:51
side note. this wasn't able to get into the newest release github.com/MoarVM/MoarVM/pull/1004 07:52
i did some work to try and get things compiling on aix. but i haven't tested it myself
Geth MoarVM/master: 5 commits pushed by (Samantha McVey)++ 07:53
samcv gonna merge that now
ItchyPlant, though what you just mentioned seems unrelated
ItchyPlant yes, this is something new 07:55
samcv hmm since libatomic wasn't updated i don't think 07:56
ItchyPlant I wrote all my experience with previous two versions here: www.reddit.com/r/perl6/comments/9s...9_on_aix7/
samcv yeah i read that :)
which prompted my changes which i just merged
can you show me your 3rdparty/libatomicops/src/Makefile 07:58
ItchyPlant I'm glad it had some values. :)
sure, moment...
gist.github.com/ItchyPlant/9970f24...5b3c92eb3f 08:00
samcv ItchyPlant, ok can you give me the output of `makefile -n` in the main MoarVM directory 08:02
ItchyPlant you mean 'make -n' I guess 08:07
samcv oh. yes :)
ItchyPlant gist.github.com/ItchyPlant/eddc1da...47c5815262 08:08
samcv oh. does `make -n` not do anything hmm 08:08
let me check the aix make manual
well hat's weird. it printed some stuff. but also ran some commands 08:11
-n usually just prints command it would run and not run any of them
ItchyPlant, are you using a clean working tree? 08:21
or did you update moarvm using git
ItchyPlant this is GNU make, not the IBM one but yes, --help for make says "-n, --just-print, --dry-run, --recon Don't actually run any recipe; just print them." 08:22
yes, it is a clean, just extracted MoarVM-2018.11 package
samcv ok 08:23
Geth MoarVM: ef9e65cac6 | (Samantha McVey)++ | build/Makefile.in
Make sure libatomicops build file is removed with make realclean
 08:29
samcv ItchyPlant, i'm not sure what's going on yet. and need to go to sleep soon 08:30
could you make a moarvm issue which links to the outputs you have linked to me so far? 08:31
`make` output and `make -n`
oh also the generated Makefile in that folder
ItchyPlant doing it... 08:36
samcv ok great 08:37
ItchyPlant thank you
good night :) 08:38
samcv night!
Geth MoarVM/pea: 255a21f93b | (Jonathan Worthington)++ | 3 files
Record registers holding attrs to use in deopt

And add dumping of them. This also means there's now a way in the spesh log to see which registers are holding attributes of a replaced object.		 10:47
jnthn So the log has stuff like this now:
Materializations:
0: Scalar from regs r29, r30
Deopt point materialization mappings:
At 1 materialize 0 into r0
At 1 materialize 0 into r2
Well, OK, it does with my local patches that actually use this stuff :)
Now need to handle merge of this info during inline. 10:49
Geth MoarVM/pea: 0bdf3d1e4a | (Jonathan Worthington)++ | 2 files
Merge materialization deopt info during inline
 11:18
Geth MoarVM/pea: 67bdab661d | (Jonathan Worthington)++ | src/spesh/deopt.c
Don't confuse deopt offsets and indices

We need to resolve offset to index (maybe in the future we'll just spit out the indices into the specialized bytecode and JIT output, though). Also place a materialization deopt call into global deopt.		 13:22
Geth MoarVM/pea: 7d7da3ca51 | (Jonathan Worthington)++ | src/spesh/deopt.c
Materialize objects with object attrs during deopt
 14:07
jnthn That actually seems to work :) 14:12
(For a very small, contrived example :)) 14:15
Geth MoarVM/pea: 26 commits pushed by (Jonathan Worthington)++, (Carl Masak)++
review: github.com/MoarVM/MoarVM/compare/7...537c58761a		 14:19
jnthn And that's a rebase to make sure a bug I was seeing wasn't froma missing master change
It's quite explosive once actually enabled, alas. 14:26
dogbert11 boom 14:46
jnthn Seems at least part of it is the materialization table entries should also be hypothetical :) 14:51
Or at least, we need to filter them before adding them for real.
Geth MoarVM/pea: 76597e616f | (Jonathan Worthington)++ | src/spesh/deopt.c
Note if deopt offset -> index resolution fails
 15:01
dogbert11 jnthn: is your branch making stuff faster now or is there still more work to be done? 15:12
Geth MoarVM/pea: 5cc493f340 | (Jonathan Worthington)++ | src/spesh/pea.c
Only add deopt in for allocations we replace

Otherwise, we end up with incomplete and wrong information in the table, and could potentially end up deopting something completely bogus.		 15:24
jnthn dogbert11: Hard to say in general, but it's certainly able to do optimizations - especially in combination with a Rakudo branch that does more aggressive lexical to local lowering - that eliminate some allocations, yes. 15:25
dogbert11: Still lots to do in terms of making the optimization cover more cases, though before that would come making it correctly handle deopt, which is what I'm working on at the moment. 15:26
Once it can handle *that*, and the Rakudo branch that makes this more useful can be merged, then this is probably sensible to merge.
dogbert11 cool, timotimo explained a bit yesterday about the 'partial' part in pea 15:28
I guess your deopt logic is for that 15:30
Geth MoarVM/pea: c69b455080 | (Jonathan Worthington)++ | src/spesh/pea.c
Don't forget synthetic annotations
 15:57
MoarVM/pea: 6c422b08a7 | (Jonathan Worthington)++ | src/spesh/deopt.c
Log deopt offset to index outcome
jnthn None of those solve it, alas. 16:01
jnthn saves it for when he has more brane :)
Geth MoarVM/pea: 69f352d71a | (Jonathan Worthington)++ | 2 files
Switch on using the PEA deopt mechanism

This, at present, causes quite a lot of breakage; something is still not quite right.		 16:03
jnthn Also, going to be traveling for the next week, so pushed the busted bit just in case I get chance to look :)
timotimo jnthn: if you'd say pea is a hard nut to crack, would that make it a peanut? 16:48
jnthn *groan* 16:49
jdv79 timotimo: really? 21:57
[Coke] news.perlfoundation.org/2018/11/sep...votes.html
jdv79 [Coke]: sup my man?
[Coke] 'allo 22:01
haven't seen you since... switzerland? still travelling? 22:02
jdv79 wut?! no. i've been back in "nyc" for ... 2 years. 22:05
got married
stuf
how you doi
n?
i was "abroad" for 7 month. meant to do a year but "personal shits".
but yes. last time we met was in the land of the swiss and overprised subway sandwich shops. 22:06
place was crazy
but fun
[Coke] I'm fine. switched jobs 2x (long story) since last we met. 22:08
jdv79 no more coldfusion?
i'd listen over pints. you gonna be downstate anytime soon? 22:09
anyway, let let me know - i'm out for today. [email@hidden.address] or 8455448098 might work. 22:17
timotimo jdv79: excuse me; really what? :) 23:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!