Geth MoarVM: e0cbbced5b | (Samantha McVey)++ | 2 files
Don't include 0..127 in Uni->windows-1251/2 switch

These are special cased so are unneeded. The switch should be faster as well this way.		 00:47
01:00 colomon joined 01:02 travis-ci joined
travis-ci MoarVM build errored. Samantha McVey 'Don't include 0..127 in Uni->windows-1251/2 switch 01:02
travis-ci.org/MoarVM/MoarVM/builds/337361870 github.com/MoarVM/MoarVM/compare/9...cbbced5bf8
01:02 travis-ci left
samcv jnthn: i'm not sure what to call the new ops 01:03
looks like i need at least encode, decode, encoderep variations. and maybe more? 01:04
01:15 travis-ci joined
travis-ci MoarVM build errored. Samantha McVey 'Don't include 0..127 in Uni->windows-1251/2 switch 01:15
travis-ci.org/MoarVM/MoarVM/builds/337361870 github.com/MoarVM/MoarVM/compare/9...cbbced5bf8
01:15 travis-ci left
samcv travis is having issues 01:16
timotimo samcv: new ops for what exactly? 01:22
samcv for windows-1251/windows-1252 so you can choose to make decoding/encoding strict or not 01:23
because atm it lets you decode/encode invalid codepoints
and when using a replacement, it doesn't replace invalid codeponits
timotimo oh, we don't have a settings hash or something that we can pass when creating a decoder?
samcv uh. i don't know 01:24
was just looking at how nqp::decode and nqp::encode and nqp::encoderep work 01:25
but if you know where that is in the moarvm code. i'll take a look
timotimo check the Decoder.c in the reprs folder 01:26
wait, you're talking encoder 01:28
samcv well both
encoder and decoder
timotimo i suppose decoder gets its own repr because stream decoding is A Thing 01:29
it'll be fun when encoding requires us to know multiple graphemes in advance because someone came up with a very smart encoding or something :) 01:35
02:24 Ven`` joined 02:58 ilbot3 joined 03:22 colomon joined 03:39 MasterDuke joined 04:19 colomon joined 04:32 Ven`` joined 05:21 Zoffix joined
Zoffix This weeks Perl 6 Weekly, hot off the press: p6weekly.wordpress.com/2018/02/05/...-squashed/ 06:29
07:07 travis-ci joined
travis-ci MoarVM build errored. Samantha McVey 'Don't include 0..127 in Uni->windows-1251/2 switch 07:07
travis-ci.org/MoarVM/MoarVM/builds/337361870 github.com/MoarVM/MoarVM/compare/9...cbbced5bf8
07:07 travis-ci left 07:11 brrt joined
brrt i'm thinking the travis issues are expr JIT related 07:46
because they started happening after mering MasterDuke++s commits. which suggests to me that the expr JIT is doing something wrong
.tell Zoffix fwiw, the adding of a NOOP expr JIT operator was a bugfix (one of thsoe that warrents a story, sometime :-)) 07:48
yoleaux brrt: I'll pass your message to Zoffix.
samcv good * brrt 07:51
brrt good * samcv 07:52
evening for you i assume?
samcv yep
brrt travis issue are travis problems, not obviously JIT problems :-) 07:53
samcv i want my money back! 07:54
brrt
.oO( Did anybody pay for travis? )
 07:55
samcv no :)
07:59 domidumont joined 08:02 domidumont joined
nine brrt: I've got a suspicion about the Travis issue. I think the JIT is innocent as the code is run only once. I think it's just tht^Hat the version string we get is empty. 08:05
(typing blindly as the train's internet connection is flaky at best)
brrt: speaking of the JIT. I wonder what the optimizer you are working on actually does?
08:07 Zoffix left 08:09 domidumont joined 08:11 brrt joined 08:51 zakharyas joined
nine brrt: yes, it was an issue in tools/build/gen-version.pl with Travis not fetching git tags 09:38
brrt ah, ok
how was FOSDEM btw?
nine Kinda odd to be honest. Almost none of the people I expected were there. 09:39
brrt :-( 09:40
yeah, couldn't come either :-(
09:40 bloatable6 joined
nine My train ride there was highly successful though and so far the ride home is looking quite good as well. 09:41
trains++
brrt hehe
nine did you read my question about the JIT optimizer?
brrt i did not
nine Wondering what it does or will do :) 09:42
brrt oh, so, the basic idea is to have a tree-rewriting step that is based on the structure of the tree and (eventually) spesh facts on the nodes
nine Ah, missed your quit message. Saw it only now.
brrt i'm seeing it on the backlog 09:43
nine What would be the goal of those rewrites?
brrt most of the ones i've implemented are strength reductions
and better-tilings
so, for instance 09:44
all (COPY) nodes of (CONST) values are redundant
this is bad because the (COPY) node is transparent to the tiler, so any time we could have had (ADD REG (CONST)) we're going to get (CONST) -> REG and (ADD REG REG) 09:45
i.e. we're using more instructions and more registers
removing those (COPY) nodes makes the tiling better
another instance
we have a number of cases that are (ADD REG (CONST x)) and lots of those can be optimized to (ADDR reg x) 09:46
or, (IDX reg (CONST x)) which can be reduced to (ADDR reg x*s)
nine Makes total sense to me, yes. 09:47
brrt one of the more tricky ones that i'm interested in, is, given we have the spesh fact that something would be always a concrete object, to remove the (is_concrete) check from the tree
nine Haven't looked at that part of the expr JIT much, but couldn't (IDX reg (CONST x)) be solved with a tile for that case? 09:48
brrt could be, but that means we need to implement it for each and every architecture
also, and this is the worrying bit, I think cost computation is wrong for the tiler
nine Isn't is_concrete removal an optimization that spesh is supposed to do? Or at least would be better suited for that level?
brrt well, many ops have a concreteness check embedded in them 09:50
the question is, do we replicate each and every such op with a sp_ variant,
or do we remove them automatically?
i'm not really sure either way 09:51
nine Ah, looks like of the ops that do a check for concreteness only very few have templates yet. And those that do check for is_type_obj instead. 09:55
samcv i still need to figure out how to name my functions
brrt MVM_doit_123() of course
MVM_doit_now()
MVM_do_more_v2() 09:56
samcv ugh. i'm not sure what's causing this. but my files keep getting an 'e' added to the end of them
i now have copies of all moarvm git files but with an e at the end
brrt: but i added some badly named functions, and they seem to work in nqp 10:03
nqp::encode2("inputstring", "windows-1252", $buf8.new, 1) and the last argument is the only new one. and 1 has it throw if trying to encode a codepoint not in that codetable 10:05
and then nqp::encoderep2 which is like encode, but you also supply a replacement string. and so currently it won't replace invalid codepoints if they fit within 1 byte. but if you use the new option then it will replace those that have no proper mapping 10:06
brrt can you actually use those functions? 10:09
samcv well i added a few nqp tests 10:10
and it passes the two variations of encoderep2, replacing all cp with no mapping with replacement or only ones that don't fit in one byte
10:14 zakharyas joined 11:13 colomon joined 11:19 AlexDaniel joined 11:27 zakharyas joined 11:44 AlexDaniel joined
Geth MoarVM: d2da85f1b2 | (Stefan Seifert)++ | src/spesh/optimize.c
Revive removal of dead instructions after the first inlined function

Previously the inlined blocks were appended to the block list, thus stopping on the first inlined block was safe. Now that blocks are inlined in the place where the actual call happened, there may be blocks we should process after the inlined blocks.		 12:09
12:26 travis-ci joined
travis-ci MoarVM build errored. Stefan Seifert 'Revive removal of dead instructions after the first inlined function 12:26
travis-ci.org/MoarVM/MoarVM/builds/337519633 github.com/MoarVM/MoarVM/compare/e...da85f1b261
12:26 travis-ci left
nine jnthn: t/spec/S02-types/num.t has been segfaulting when run with MVM_SPESH_BLOCKING and MVM_SPESH_NODELAY since I fixed MVM_spesh_log_decont in 39928851f8. Apparently we end up with a stable_type_tuple with neither decont_type nor type. I have a workaround for the segfault but I guess such a type tuple shouldn't appear in the first place? 12:48
dogbert2_ nine: I wrote an issue for that the other day: github.com/MoarVM/MoarVM/issues/791 12:57
given what you wrote above my 'bisect fu' needs to improve a lot :-) 12:58
nine dogbert2_: knowing what my commit does helped a lot in interpreting what I saw in gdb 13:08
dogbert2_ nine: how was FOSDEM? 13:11
jnthn nine: Well, unless it's a callsite with all native args, but perhaps then we skip type tuples entirely... 13:12
nine dogbert2_: not at all how I expected. Saw almost no one of the people I thought would be there and only exchanged about 2 sentences with tadzik. 13:13
jnthn: that....doesn't really tell me if I should commit the workaround :)
jnthn nine: Can you gist it? :) 13:14
nine jnthn: gist.github.com/niner/68f3825e06c3...2c80ffd104 13:15
dogbert2_: I did have interesting talks with random people though and learned some about leadership from mdk++. Also I got the impression that people approaching the Perl booth were more interested in Perl 6 than Perl 5. 13:17
Though the latter may just have been because the front row of books was about Perl 6. Also it's kinda hard to answer with something but Perl 6 when a Python user asks why he should learn Perl. Nowadays Perl 5 just has no clear advantage over Python while Perl 6 does. 13:18
dogbert2_ nine: were there any interestings talks? 13:19
nine dogbert2_: I'm sure there were ;) Alas, I didn't even get to the Perl devroom and other rooms I tried to get into were usually full. I think it's fair to say that nowadays if you want to watch FOSDEM talks live, it's better to stay home ;) 13:21
dogbert2_ :-) 13:22
timotimo nine: there's still is_concrete bits (and also reprid checks) in the implementations of functions that are currently "just called" from the lego jit 13:40
oops, i was scrolled up 13:41
jnthn nine: Yes, seems OK as a workaround 13:48
Geth MoarVM: 0e737146b7 | (Stefan Seifert)++ | src/6model/reprs/MVMMultiCache.c
Work around a segfault caused by type tuple without type information

Somehow the fix to MVM_spesh_log_decont in commit 39928851f8 facilitated the appearance of type tuples with neither decont_type nor type filled. This caused segfaults when trying to identify the correct multi candidate. Work around this by checking for this situation and failing to match.		 13:51
nine jnthn: when there is a dead instruction (result of a pure op not used anywhere) in the After: spesh dump, does that mean it's worth looking into removal of more dead instructions in MVM_spesh_optimize or is there some other layer where they are removed? 13:54
timotimo check how the "dead writer" flag is handled 13:55
jnthn nine: No other layer; note that some things are kept alive not because they are needed in the optimized code, but because they may be needed if we deopt 13:59
We're quite conservative on that at the moment 14:00
For example, don't check if a guard really was inserted
nine jnthn: a deopt annotation would indicate that situation?
jnthn At the moment, if the reader is the opposite side of a deopt annotation from the writer, then we give a usage bump of 1 14:01
Effectively meaning "used by deopt"
That is safe, but not precise.
The problem we're addresing here is: 14:02
blah r1, ...
blah r2, ...
guard on r2 that may deopt
Given this situation, it could be followed by: 14:03
orig_unoptimized_instruction r3, r2, r1
Which is optimized into
new_optimized_instruction r3, r2, 42
nine The situation I'm looking at is: [Annotation: INS Deopt One (idx 0 -> pc 30; line 445)] sp_p6oget_o r26(3), r6(3), liti16(16) [Annotation: INS Deopt One (idx 1 -> pc 56; line 445)] sp_p6oget_o r21(3), r6(3), liti16(16)
With r21(3) not referenced anywhere else
The only other appearance in the log it makes is: r21(3): usages=14, flags=13 KnTyp Dcntd Concr 14:04
jnthn Now, if the guard fails, then we have to deopt. We'd then run the original instruction, which depends on r1's writing instruction having run.
So we cant optimize that away because if we deopt we need it 14:05
The "usages=14" means it thinks there are 14 ways in which it might be used
One thing that could be done is to start to track the number of usage bumps that are a result of preserving things in case of deopt 14:06
nine Ah, so I have to look at the Before: dump and check if the "unused" result may be used there after a deopt
jnthn Right
At the moment, we don't ever try to decrement "unrequired" deopt-induced bumps
14:07 travis-ci joined
travis-ci MoarVM build passed. Stefan Seifert 'Work around a segfault caused by type tuple without type information 14:07
travis-ci.org/MoarVM/MoarVM/builds/337556956 github.com/MoarVM/MoarVM/compare/d...737146b73d
14:07 travis-ci left 14:16 zakharyas joined
nine We also seem to have quite a lot of rather useless set instructions from one register to another where we never use the original register's value again, i.e. we could just keep it there and work with the original register. 14:45
But I guess eliminating those is territory for some clever comp sci algorithm that I've never heard of 14:47
brrt no, i think the reason we keep them is because of deoptimization possibilities 14:48
timotimo that's the case for some at least
nine So another case of me needing to beef up my deopt reading skills 14:49
brrt well
if you want to remove that, then yes
nine I figure if we want to become faster, we have to remove wasteful code ;) 14:50
brrt i kind of agree ;-) 14:52
i don't know, but i figured we'd need to build a deopt-divergence map of some kind
and maybe even go so far as to associate that with the deopt point 14:53
nine Regarding deopt, the way I read it is that the only opts that cause a deopt_one are the sp_guard* ops and the only ops to cause a deopt_all are rebless and sp_rebless. The latter may appear in any callee. So deopt points are sp_guard* ops, rebless ops and anything invokish, right? 14:54
jnthn nine: Yes, and there are annotations indicating both of these cases 14:56
We also have, at the end of optimize, a pass to remove guard instructions that were unused
Since not all guards are used 14:57
nine jnthn: those are the INS Deopt One annotations?
jnthn Yes
And Deopt All in invoke things
nine But a sp_p6oget_o is neither an sp_guard* nor invokish, so it shouldn't carry that annotation? 14:59
jnthn That almost certainly means the annotation was on such an instruction and then moved 15:00
Oh...or
That instruction was rewritten from one that could cause a guard
nine I'd guess it was originally on a decont
jnthn Right
Most deconts on hot paths become set or sp_p6oget_o 15:01
nine So when rewriting that we ought to remove those annotations, even if for nothing else than to make the spesh log easier to understand 15:03
jnthn I can't remember whether the annotations are put onto the instruction of its guard
*or its guard
facts.c has the code doing that
But it may also be that they are on the guard and they move when the guard is deleted due to being unrequired 15:04
But the rewrite of a decont into an sp_p6oget_o does *not* mean that there is no guard following it
Just because we spesh the decont doesn't mean the guarding of what we got out of the decont goes away 15:05
nine I see matching Deopt One annotations on the decont in the Before: dump
jnthn OK 15:06
Then they're left on the instruction that could be guarded 15:07
15:07 p6lert joined
jnthn Oh. Since we don't have guards at CFG construction time (they are inserted in the facts pass), of course it's easier for the deopt annotations to go onto the instruction that produces the guarded value. 15:08
I was thinking "I coulda done it either way", but the other way woulda meant moving the annotation afterwards
nine Huh? There's code in facts.c for /* Move deopt annotation to the guard instruction. */ 15:13
jnthn Oh :D 15:17
So I wasn't so lazy after all ;-)
haha
It's probably just easier to read the code for details ;) 15:18
It used to be the case that we resolved deopt instructions by index though
Uh, bytecode positon rather than index, I mean
Now we don't do that
And just emit the deopt index directly into the bytecode instructions and, iirc, fix those up on inline
So perhaps I was forced to do the move to make the position lookup work out 15:19
nine If that does as advertised the sequence seems to be build_cfg adding a DEOPT_ONE annotation, log_facts adding a guard and moving the annotation there and then some other optimization removing the guard and moving the annotation onto the spesh op
jnthn Sounds likely enough 15:20
Removing the guard will just be a normal instruction deletion
iirc at least, though we've seen today I usually don't ;P
But in that case it'll just be the normal annotation movement code in instruction deletion that moves it. 15:21
nine And that's code that I've already spent hours with during those dark inline in place months :D
jnthn :) 15:22
nine I'll probably just add an option to MVM_spesh_manipulate_delete_ins for dropping those annotations.
jnthn I wonder if there's ever a legit case for moving a deopt_one?
nine Some Jonathan Worthington seemed to think so and write quite a bit of code to handle those 15:23
moritz that guy tends to not write large amounts of code that is never triggered :-) 15:25
nine But that code also contained a bug (which I fixed in 2d2c4ce734) that caused those annotations to get lost, so it could not have been hugely important
Looks like a good time for ye olde "rip it out and see what breaks" approach 15:26
jnthn nine: If I had to guess, we'll get errors about missing things when building the deopt table 15:28
That's more a "bookkeeping" check than anything, however
nine Observtion 1: spectest looks just fine without the DEOPT_ONE moving code. Observation 2: removing that code does not actually get rid of the DEOPT_ONE annotations on sp_p6oget_o. 15:41
15:45 [Coke] joined 16:00 AlexDaniel joined
nine In fact, even disabling guard removal doesn't seem to make a difference. 16:04
16:17 samcv joined
nine I start doubting that a guard is eve rinserted in my case. 16:22
jnthn Possible, if there's no data
Or no stable type
nine Then the annotation is still the original one 16:23
16:29 brrt joined 16:37 brrt1 joined 16:43 brrt joined 16:44 brrt1 joined 17:04 zakharyas joined 17:21 zakharyas joined 18:01 domidumont joined 18:03 zakharyas joined 18:04 zakharyas joined 18:07 zakharyas joined 18:20 bart__ joined
Geth MoarVM/jit-expr-optimizer: 13 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/3...ac876f06a4		 18:23
19:46 evalable6 joined 19:49 Kaiepi joined 20:11 committable6 joined 20:14 bart__ joined 20:20 committable6 joined 20:23 samcv joined 20:44 zakharyas joined 20:58 samcv joined, dogbert17 joined 21:00 samcv joined
dogbert17 .seen brrt 21:05
yoleaux I saw brrt 14:53Z in #moarvm: <brrt> and maybe even go so far as to associate that with the deopt point
dogbert17 GH #1483 seems JIT related, it disappears when using MVM_JIT_DISABLE=1 21:07
22:36 harrow joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!