github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:36 Kaiepi left 00:40 committable6 left, nativecallable6 joined, statisfiable6 joined, bisectable6 joined, greppable6 joined, committable6 joined
Geth MoarVM/extra-usage-chains-fixes: b1a0fb8301 | (Timo Paulssen)++ | src/spesh/inline.c
missing writer setting in inlining (return val boxing)
 01:01
MoarVM/extra-usage-chains-fixes: 31779ab2c6 | (Timo Paulssen)++ | src/spesh/optimize.c
Correct writer setting in coercing via elems
MoarVM/extra-usage-chains-fixes: 6caf14acb1 | (Timo Paulssen)++ | src/spesh/optimize.c
(optimize_not_i) this could be wrong

but it seems to advance speshing to an optimize_iffy, which i assume came next after this optimize_not_i.
timotimo ^- the last commit may want a closer look. feel free to cherry-pick or rebase or straight-up steal the others
still not getting past the first file in nqp
01:29 stmuk_ joined 01:32 stmuk left 01:37 benchable6 joined 03:55 MasterDuke joined 05:04 stmuk joined 05:06 brrt joined 05:07 stmuk_ left
brrt \o 05:56
06:16 releasable6 joined 06:29 robertle joined 06:44 domidumont joined 06:49 domidumont left 06:50 domidumont joined
brrt what would we think of aliging nursery allocations either at or within a cache line 07:00
(assuming 64 bytes cache line size)
nwc10 first question I'd ask is how much "wastage" this rounding would cause?
(I assume that it increases nursury throughput, but is that extra pressure massive?)
actually, second question is "does the increase in cache misses due to using more memory overall cost more than the alignment wins?" 07:01
brrt the answer is 'I don't know'
the reason I'm asking is that I want to figure out how much I can affort to make MVMString larger with an in-situ buffer
nwc10 OK, but they seem like useful things to estimate
aha. So *it* would always grow to a cache line 07:02
and everything else gets the extra space/alignment for free?
brrt That would be one possible way of doing it, yews
I don't know how many small objects we have, most of them probably are, I think
*afford 07:03
nwc10 OK, I'm not sure if I can add anything more intelligent to this than I'd be curious about those two questions
brrt It'd probably depend on the size distribution of objects
my guess is that most objects will be smaller than 64 bytes
at most, we're doubling our nursery usage because we'd be leaving 31-byte holes between allocations 07:04
oh, hang on, MVMStringBody is 24 bytes, but we have to add the header to that as well 07:05
ok, so with everything in it, we have 48 byte string object header 07:10
to fill that up to 64 byte, we can still add 16 bytes, giving us a 24 byte string 07:12
or, a 6 grapheme string 07:13
that would mean most of rakudos keywords etc. would fit in-situ
on the other hand, the fact that our header is 24 byte already, makes it quite unlikely that any objects can share cache lines 07:19
07:31 brrt left 07:56 zakharyas joined 07:58 zakharyas left 08:03 dogbert17 left 08:06 benchable6 left 08:07 benchable6 joined, nativecallable6 left, statisfiable6 left, bisectable6 left, greppable6 left, committable6 left, committable6 joined, greppable6 joined, bisectable6 joined, statisfiable6 joined, nativecallable6 joined 08:08 releasable6 left 08:23 domidumont left, lizmat joined 08:25 domidumont joined 08:30 AlexDaniel`` joined
samcv when is the --no-jit going to be fixed? would like to bump moar soonish 09:03
09:05 releasable6 joined
nwc10 samcv: not sure, but we're safe from football-shaped distraction for about 33 hours 09:05
Geth MoarVM: 4830f82326 | (Samantha McVey)++ | src/jit/core_templates.expr
Add add_I expr JIT template and sort expr templates
 09:10
jnthn samcv: Not sure how long it will take to fix; the way it breaks gave very few clues. I'll have a got at it later today 09:21
samcv okay. thanks
09:22 ilmari left
jnthn *go 09:22
09:23 ilmari joined, ilmari left, ilmari joined 09:28 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Add add_I expr JIT template and sort expr templates' 09:28
travis-ci.org/MoarVM/MoarVM/builds/401674450 github.com/MoarVM/MoarVM/compare/a...30f823263a
09:28 travis-ci left 09:30 brrt joined 09:41 brrt left 09:43 klapperl joined
jnthn Taking a look at the no-jit issue now 10:32
Might be deopt related. 10:35
The frame it's in when it crashes is also the last one that was reported to have deopted
10:36 zakharyas joined
samcv jnthn: is that related to the appveyor issue too? 10:40
jnthn No idea 10:41
Does it try a --no-jit build? If so possible
(Or if it's a 32-bit build, then yes, because there's no JIT available for that.)
10:41 brrt joined 10:50 AlexDani` joined 10:52 AlexDaniel left
Geth MoarVM: 0e11082046 | (Samantha McVey)++ | 13 files
Make a faster HASH_ITER macro and make other hash optimizations

HASH_ITER_FAST is faster and it doesn't randomize bucket order (though it's faster regardless of that).
Makes the biggest difference when we are iterating a hash with a LOT of keys in it, such as adding a million keys to a hash then deleting and ... (8 more lines)		 10:59
MoarVM: a2ca33bad9 | (Samantha McVey)++ (committed using GitHub Web editor) | 13 files
Merge pull request #901 from samcv/iterspeed

Make a faster HASH_ITER macro and make other hash optimizations
MoarVM: caef82f1bd | (Jonathan Worthington)++ | src/spesh/inline.c
Correctly update OSR deopt index upon inlining

Otherwise, we end up with the wrong index, which leads to overwriting the correct deopt offset with a bogus one. This caused a crash when building NQP with JIT disabled, introduced since we started being able to inline non-specialized code. This wasn't originally noticed, since the JIT doesn't care for those indexes, and so everything worked under JIT, and only failed in the case of running quickened bytecode.		 11:05
jnthn samcv: ^^ seems to help, guess Travis will tell us soonish :) 11:06
lizmat whee!
samcv yay
jnthn lunch time, bbiab 11:07
brrt jnthn++ 11:16
(one line fixes++) 11:17
11:27 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Correctly update OSR deopt index upon inlining 11:27
travis-ci.org/MoarVM/MoarVM/builds/401710670 github.com/MoarVM/MoarVM/compare/a...ef82f1bd5a
11:27 travis-ci left
samcv \o/ 11:31
nwc10 jnthn++ # a very well earned lunch 11:32
brrt first approximation says that for most object types, we can never share a cache line 11:33
also, that we'd be using nursery space approximately 50% faster 11:34
(so that we either need more nursery space or accept more GC)
timotimo i do believe the nursery size is this size because of l2 cache size? (or l3?)
brrt that is processor dependent though :-) 11:35
as in, you buy a more expensive machine, you get more cache 11:36
timotimo mhm
11:51 zakharyas left 11:52 zakharyas joined
samcv brrt: windows appveyor says: src\jit\x64\emit.dasc:2927: error: missing operand size in `mov x?,i?': 11:59
ci.appveyor.com/project/samcv/moar...3we2x#L442 shows up on 32 and 64bit 12:00
brrt hmmm 12:01
nwc10 paste.scsys.co.uk/578897 -- ASAN very very excited by the NQP build - use-after-free everywhere. 12:02
backtraces have src/6model/reprs/MVMHash.c
lizmat samcv: ^^^ 12:03
nwc10 I *think* that it's that, but now testing the commit before jnthn's last one to be more confident 12:04
samcv yeah guessing it's my change
nwc10 yes, not jnthn's most recent change
in case it matters, I have 12:05
+#define FSA_SIZE_DEBUG 1
and
+#define MVM_ARRAY_CONC_DEBUG 1
jnthn Phew, I'm off the hook for once :)
nwc10 and 12:06
MVM_SPESH_BLOCKING=1
MVM_SPESH_NODELAY=1
samcv: yes, it's commit 0e11082046de74f1c1cb78fda6993b668fe8eca1 12:14
Geth MoarVM: cb9ddae582 | (Bart Wiegmans)++ | src/jit/x64/emit.dasc
[JIT] Add sizes to ARG5/ARG6 memory definitions

Otherwise DynASM on windows will rightly complain		 12:19
brrt samcv++
jnthn figures he should try and get his Rakudo rescalar branch into mergeable shape before pressing ahead with the du-chain stuff
Geth MoarVM: 26860430a7 | (Jonathan Worthington)++ | src/core/frame.c
Don't leak a real NULL from getcodeobj

We should only ever store a VMNull into a register, not a real NULL.		 12:28
jnthn m: use nqp; say nqp::iscont(item(my %h)) 12:32
camelia 1
timotimo that sounds like it's the source of these segfaults in guard instructions 12:34
12:36 travis-ci joined
travis-ci MoarVM build errored. Bart Wiegmans '[JIT] Add sizes to ARG5/ARG6 memory definitions 12:36
travis-ci.org/MoarVM/MoarVM/builds/401734087 github.com/MoarVM/MoarVM/compare/c...9ddae58238
12:36 travis-ci left
brrt oh, that is apt hate 12:39
jnthn timotimo: Yeah, there were two crashing tests in rescalar thanks to that 12:42
timotimo i think i also saw it in profiling related crashes 12:44
jnthn: i took the liberty to make an edit in your callwith/callsame example; you appear to have copy-pasto'd 42 in the second example instead of 4.2 12:45
only in the "cando" case, not the actual call example directly below it 12:46
jnthn timotimo: ah, thanks :) 12:48
13:14 zakharyas left
samcv nwc10: ok i figured out the asan errors 13:37
nwc10 \o/ (I hope)
samcv well i fixed that issue. now i have a different one :P
ah probably because i didn't change uthash.h i just edited it into that file. 13:38
Geth MoarVM: ed7ab67735 | (Samantha McVey)++ | src/strings/uthash.h
Fix asan errors by assigning before assigning hh_next

It worked fine most of the time, just had issues when you tried to free the entries while iterating. If you tried to free what held the next reference ASAN would complain, and would likely cause issues in the future.		 13:48
MoarVM: c42255f865 | (Samantha McVey)++ | src/math/grisu.c
Use a macro for unsigned long long on MSVC

Before we were just ignoring the warning with a pragma. I thought I read that older MSVC's didn't support it, while newer will warn, but regardless, use the format MSVC wants.		 13:50
brrt samcv++ (this has bitten me 100 times) 13:51
samcv brrt: what did you end up doing? 13:52
also i was thinking of making MVM_C_CONSTANT_I32 since Unsigned is different size on linux than windows
brrt not the unsinged long thing, although I've fixed that with ... some other header 13:54
samcv wonder do we check the size of long's and int's?
oh which thing?
the asan messages?
brrt yeah 13:55
samcv sorry :P
brrt :-)
it happens when you write C
samcv i tested it heavily, though less heavily with ones that free'd objects
so i tested it all, then ended up changing almost all of them
brrt
.oO( I wonder why they call C 'insecure' )
nwc10 samcv: looks good. build ongoing
brrt one of my existential worries is that I'm writing C and ... in the future no-one will
nwc10 previosly there was an explosion of multicoloured pavement pizza within a few seconds 13:56
All tests successful. 13:59
samcv brrt: so you think there's a header file that defines ULL for windows? or what.
wasn't sure you could define suffixes with macros
Geth MoarVM: cae4731e2c | (Carl Masak)++ | docs/bytecode.markdown
Fix typo
 14:02
brrt hmm, i thougth that'd be stdint 14:15
(hey, masak lives ;-))
samcv: stdint.h has macros for sized integer constants 14:42
in src/core/bitmap.h i'm using that for example to get an usigned 64 bit '1'
UINT64_C(x); you could have the same for UINT32_C 14:48
Redfoxmoon one of my existential worries is that I'm writing C and ... in the future no-one will <-- no matter the amount of hipster languages, that will never change :P 14:49
samcv brrt: oh nice 14:50
brrt Redfoxnoon: I don't know 14:51
I would've thought C was 'stable' in place for a couple more years. But 'security' is becoming more and more important 14:52
Redfoxmoon *for sure*
You can write secure C code
brrt but people don't
Redfoxmoon so?
you can write shit code with hipster languages too...
brrt and learning to write secure C code is so vastly different from learning to write perl code
or java code or even from c++ code 14:53
14:53 dogbert17 joined
brrt substitute 'secure' with 'good' and it's still true 14:53
Redfoxmoon :P
but you still need C to write the bedrock for the new hipster languages
brrt you kind of don't
Redfoxmoon I don't exactly see perl becoming a true compiled language just yet. 14:54
timotimo yeah, wouldn't they self-host?
brrt writing an assember isn't that hard of a job
Redfoxmoon :P
timotimo "it's too hard to write secure C, so we decided to write assembly instead"
brrt Redfoxnoon: no (although I'd like to have it :-))
a self-hosting language would need an assembler at some point
Redfoxmoon I'd like moarvm to not use any perl5 crap first
:-)
something-something native windows port 14:55
timotimo crap? that's not a nice thing to say.
Redfoxmoon perl5 is an ungodly mess :/
It's even worse when you're dealing with a PE target where you can't have undefined references at link time 14:56
timotimo what is PE?
i knew it once 14:57
Redfoxmoon The executable format used by win32 on Windows :P
timotimo oh, i knew that 14:58
i thought it was something more general
Redfoxmoon so yeah.
I wanted to add moarvm to midipix, a new posix layer for windows, but as our perl5 port is currently broken due to PE versus ELF issues 14:59
that's impossible:-)
brrt Redfoxnoon: I happen to like perl5
Redfoxmoon perl5 is an okay language, the reference implementation is not
brrt have you tried Perlito :-) 15:00
Redfoxmoon I dare say it's horrible
isn't that dead
brrt anyway, can the perl 5 porters folks help you
well, not really
Redfoxmoon I asked, but since we're using perl-cross to build the thing -at all-
I don't think they're gonna be willing to put any serious effort in.
brrt hmmm
anyway, I can't speak for that 15:01
having perl5 as a build-time dependency is something we've discussed
dogbert17 turns out that brrt's objprimunsigned fix managed to resolve github.com/MoarVM/MoarVM/issues/890
Redfoxmoon cross compilation with the default build system for perl5 is...bad:-)
it basically requires an SSH server on the target to run tests on.
brrt dogbert17: yay!
timotimo how else are you supposed to test, though 15:02
brrt (don't run tests then?)
Redfoxmoon :')
dogbert17 brrt, will make a comment to that effect and close it
brrt ty 15:03
Redfoxmoon Yeah I wish.
jnthn Anyone know any reason not to bump MOAR_REVISION in NQP at present?
lizmat doesn't 15:04
and would welcome one
Redfoxmoon it might be doable to manually feed in *EVERYTHING* it needs to test for in the default build system for perl5 needs
but then there's still the PE versus ELF issue
lizmat jnthn: want me to do it ?
jnthn lizmat: No, already got it done, just wanted to ask before pushing :) 15:05
lizmat okidoki
jnthn I did a SEGV fix earlier than is depended on by the rescalar branch 15:07
dogbert17 I believe that we're problem free atm (famous last words)
jnthn Well, certainly the problem free() was fixed by samcv++ :) 15:08
dogbert17 I'll rebuild and try to break it but I suspect that nwc10 has already found everything of note :) 15:10
15:10 brrt left
timotimo jnthn: will we be using the results from du-chains to fix spesh usage counts on master before the release and merge du-chains after the release? 15:11
jnthn No, because the API for mainpulating spesh usage counts changes with it 15:13
I think we'll be able to get it fixed up and merged this week
timotimo i meant not the code but the knowledge about missing places for usage calc
but that's fine, too :) 15:14
lizmat that brings test-t below 2 seconds for me 15:15
timotimo what was it before?
lizmat just above it
timotimo OK, so not likely going to get tux below 2, too ;)
lizmat I don't think so, but below 2.2 would be possible, I think 15:16
jnthn lizmat: Which "that"?
lizmat your MoarVM bump
jnthn ah :)
lizmat well, we'll know shortly, I guess
jnthn: your last merge commit seems to have made things slower, is that to be expected ? 15:22
timotimo by how much?
jnthn lizmat: It's not surprisng. 15:23
I've still a list of things to tune
lizmat .930 -> .965 for test-t --race
jnthn m: say .930 / .965 15:24
lizmat also: memory use for building seems to top out at 1.24G atm, not sure what it was before
camelia 0.963731
jnthn I didn't yet put in optimizations for hash auto-viv, nor Nil assignment 15:25
Those could easily account for something
lizmat ok... so one step back to be able to take N steps forward
:-)
timotimo hopefully N² or better :P
lizmat hmmm... noise
now I got a test-t run of .908 15:26
which would make it better than before
grrr
jnthn Yes. The change here is to provide a path to doing various other important things, so much as the immediate win.
heh :)
The -20 ones are perhaps less noisy
I figure I'll focus on the du-chains stuff next, then return to more opts for the Scalar stuff after 15:29
Geth MoarVM/du-chains-and-opts: 8e63146013 | (Timo Paulssen)++ (committed by Jonathan Worthington) | src/spesh/inline.c
missing writer setting in inlining (return val boxing)
 15:35
MoarVM/du-chains-and-opts: c1cc62679d | (Timo Paulssen)++ (committed by Jonathan Worthington) | src/spesh/optimize.c
Correct writer setting in coercing via elems
15:45 zakharyas joined
Geth MoarVM/du-chains-and-opts: baa7f66947 | (Timo Paulssen)++ (committed by Jonathan Worthington) | src/spesh/optimize.c
Fix optimization of isfalse to set writer
 15:48
jnthn timotimo: Took first two as is, third with corrections. Thanks!
Geth MoarVM/du-chains-and-opts: 23ecdc5a76 | (Jonathan Worthington)++ | src/spesh/usages.c
Add check that all readers in DU chain are present

This makes sure that we don't have any reads that are not represented in the users list.		 15:54
15:59 domidumont left 16:20 domidumont joined
Geth MoarVM/du-chains-and-opts: 59fc280ce3 | (Jonathan Worthington)++ | src/spesh/usages.c
Ensure a big PHI can't cause an overflow
 16:28
MoarVM/du-chains-and-opts: 0ef24ff9f0 | (Jonathan Worthington)++ | 2 files
Correct various missing usage bumps
MoarVM/du-chains-and-opts: 673a8a2734 | (Jonathan Worthington)++ | src/spesh/optimize.c
Don't do the usage validation so often

It's rather costly, and slows things down a good bit too much to do it after each processed instruction.
MoarVM/du-chains-and-opts: b558cc9e25 | (Jonathan Worthington)++ | src/spesh/args.c
Fix spesh arg box writer/usage handling
 16:34
jnthn Damn, the usage checks are slow :)
But it's getting a lot further now :)
Oh, it's doing them every BB
Geth MoarVM/du-chains-and-opts: 11fcf2a85e | (Jonathan Worthington)++ | src/spesh/optimize.c
Check usages one after main opts

Checking it after every basic block is too much of a slowdown, now that we get quite far with the checks enabled.		 16:43
jnthn With MVM_SPESH_BLOCKING=1 on, that branch now reaches the NQP test suite and fails 2 tests
Will do it under NODELAY after fixing that, to tease out some more issues
And once that lot is working, will write the third check, which is making sure that there's no bogus entries in the usage list 16:44
cooking & 16:46
16:59 zakharyas left 17:17 brrt joined
[Coke] misreads BB as "big blind" 17:21
yoleaux 16:48Z <Zoffix> [Coke]: sent you an email about my grant
17:24 AlexDani` is now known as AlexDaniel 17:56 brrt left 18:02 MasterDuke left 18:54 domidumont left 19:24 domidumont joined, AlexDaniel left 19:25 domidumont left
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/07/09/...to-perl-6/ 20:17
moritz lizmat++ 20:33
20:51 MasterDuke joined 21:27 MasterDuke left
samcv lizmat++ 21:27
21:29 MasterDuke joined 21:36 brrt joined
brrt I have a mad plan 21:49
I want to make MoarVM fork()-safe
I'm fairly sure this is possible 21:50
jnthn *sob* 21:56
I...really? :)
brrt why the cry? 21:57
jnthn I suspect it's technically possible but...at what cost?
brrt of leveraging completely unrelated functionality, of course
we already have a gc sync point mechanism, don't we
so, we can ask nicely for all threads to join up, and provided they're not infinitely looping in nativecall, eventually they will 21:58
when that happens, the fork-ing thread either has to stop, or pause, the uv loop thread and spesh thread 21:59
jnthn The thread pool scheduler is by a bunch of threads waiting on a condvar
brrt better still 22:00
jnthn And never willingly exits
Of course to some degree we control the execution
But still, locks, threads waiting for locks, etc.
brrt again, provided no deadlock happens
and i'm not saying this mechanism isn't about to be very expensive 22:01
timotimo one way to kill threads is to send a task over that throws a specific exception to stop the work loop
brrt i'm fine with ridculously expensive mechanisms
(yes, or maybe some simpler sentinel value) 22:02
what i'm not entirely at ease with, is telling people that the only concurrency mechanism we give is a thread
there is more than one way to do it, etc 22:03
Geth MoarVM/du-chains-and-opts: 2f88d0e249 | (Jonathan Worthington)++ | src/spesh/plugin.c
Set writers on spesh plugin getattr code-gen
brrt so yeah, I think there'll be a cost, but that cost would only be payed by a user who actually forks() 22:06
*paid 22:07
i'd be happy already if nothing came out of it but a way to run ASAN-clean without MVM_SPESH_BLOCKING 22:11
i.e. that allocations in the spesh thread would not be considered leaks
MasterDuke it'd also be nice if --full-cleanup worked 22:14
brrt yes :-) 22:15
TimToady +1 to making impossible things merely difficult 22:19
as long as no implementors are tormented in the process...oh wait... 22:20
brrt hehe
I'm not saying it'll be a smashing success
in all likelihood it won't
TimToady for some p5 shops, fork is a poor-man's deployment mechanism where a process is being used as a container 22:22
so a mess of forks at the beginning, then steady state 22:23
this might help such a shop
jnthn It may. Note that precomp is also done via async proc spawning, which isn't a problem if you installed all modules properly 22:24
But it's not quite as simple as "if the user didn't themselves spawn a thread then fork() is OK", because both Rakudo and MoarVM internally make use of threads.
TimToady well, just thinking about how they migrate their current million-line P5 program piecemeal to P6
jnthn s/But/So
But if we can make it survive the usages of threads in MoarVM and Rakudo that the user doesn't themselves cause, we may well be able to do it. 22:25
Heck, the precomp thing could even use a fresh scheduler and then tell it to kill its threads after. 22:26
That only leaves the spesh thread and the VM event loop thread
brrt I think that's doable, yes, and more ambitiously i'd ask the question 'do we want the user to specify if we want to restore their thraeds'
but that is maybe a bit too much madness
jnthn It is, and also this may end up with us having to build our own locks.
Which other things might force on us anyway.
brrt hmmm
jnthn (The JVM does that.)
brrt fair enough. didn't think so much ahead about locks tbh 22:27
jnthn Ah, but that's what makes this hard :)
They provide a "park" mechanism
When you have that then you can interupt a bunch more threads that you otherwise could not.
TimToady refrains from making a pun on channels and locks
jnthn :D 22:28
brrt i'm too nonenglish to see a pun, so i'm missing it :-) 22:31
anyway, /me -> sleep
i'll think about it some more :-)
jnthn
.oO( The pun, for the fork thing? :P )
 22:32
*or 22:33
jnthn wrote the third bit of the DU chain checker, now that we're almost working with the other one
Which checks if we have uses left in the chain that don't show in the graph
timotimo i.e. a user (instruction) that has been removed from the next/prev links of the instructions themselves but is still in the users list? 22:34
jnthn Or an instruction where the operand changed but we didn't delete the usage first
Basically, all the places we mis-manage usage decrements and so might keep an instruction alive when we needn't
timotimo good
jnthn reading sp_getarg_o of 0(2) not in graph 22:35
That's fascinating, given the instruction writes r0(2) :P
22:36 brrt left 22:41 AlexDaniel joined
lizmat m: { say "foo" } # this Block is run because it is sunk, is it not ? 22:42
camelia foo
jnthn oh, duh, I got the diagnostic output wrong, it's a PHI that was doing the reading... 22:44
lizmat m: say .file ~ ":" ~ .line with Block.can("sink")[0] # but the Block.sink is Mu.sink, which doesn't do anything 22:45
camelia SETTING::src/core/Mu.pm6:13
lizmat so I guess bare blocks are codegenned differently ? 22:46
jnthn Yes, it's a compile-time decision 22:48
In circumfix:sym<{ }> iirc
MasterDuke while people are around, anybody have thoughts/comments on my tuple of PRs to rename nqp::getstrfromname? 22:49
lizmat +1 from me
Geth MoarVM/du-chains-and-opts: 901ccf7692 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Instruction deletion should delete usage, not add

Thinko found while looking into unexpectedly leftover instruction usages in the graph.		 22:50
jnthn oh, fascinating, a PHI can have the same register in it twice?! 22:52
MasterDuke one things that's missing, but impossible to add ahead of time as far as i know, is MoarVM and NQP bumps in the NQP and Rakudo PRs respectively
timotimo oh, yeah 22:53
it does that a bunch of times
i tried to fix that at some point by reducing the registers in the phi to be one per version
jnthn Guess there's a sensible-ish reason
Anyway, it's a one line change for my error detector to cope with it
timotimo that's good 22:54
i also had the fun situation where a phi with only two arguments was in there, and removing it made things asplode :)
jnthn Now the detector throws up a non-PHI issue :) 22:55
MoarVM oops: Malformed DU chain: reading goto of 16(6) not in graph
I bet that's something rewritten into a goto without decrementing the usage of the conditional instruction :) 22:56
timotimo probably
should be easy to find, info.*get_op.*goto
Geth MoarVM/du-chains-and-opts: 59b6fe6b20 | (Jonathan Worthington)++ | 2 files
Add detection of missing usage deletions

So that we can find out where we have uses of values that are not in the graph, but still listed in the DU chain. This means we didn't properly delete the usage, and so might keep alive an instruction we could otherwise delete.		 22:58
MasterDuke jnthn++ just compiling rakudo now after pulling your recent merge and stage parse is definitely a second or three faster 23:00
Geth MoarVM/du-chains-and-opts: 31a1ee85d8 | (Jonathan Worthington)++ | 2 files
Fix various missing operand use deletions
 23:13
jnthn MasterDuke: Nice :-)
Calling it a night. More usage mess-up hunting tomorrow. :) 23:18
23:26 releasable6 left, greppable6 left, bisectable6 left, statisfiable6 left, nativecallable6 left, benchable6 left 23:27 benchable6 joined, statisfiable6 joined, bisectable6 joined, nativecallable6 joined, greppable6 joined, releasable6 joined, committable6 left
MasterDuke timotimo: did you ever find any optimizations for install-core-dist.pl? 23:32
timotimo i don't think my efforts went anywhere :S 23:33
though it's most likely i just got distracted too early

Powered by Cro and the Raku® Programming Language.

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

Thank you!