github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo both 00:17
i'm not sure what exactly i'd been thinking when i wrote that. when we actually know the type, and know that it's concrete or a typeobject, what we have to do should always be the same 01:02
spesh doesn't really have a code path for "this wil invoke something, i know what it will invoke, but there is no information from logging" 01:08
01:20 klapperl joined 01:21 klapperl_ left
timotimo sadly, hllizing a str, int, or num doesn't happen much during core setting compile at least 01:22
the vast majority are hash hllizes, which require an invoke, just like array and code hllizes
but str, int, and num only require an unbox_[sin] and a box_[sin] 01:23
will just have to run a spectest with spesh logs turned on 01:50
now i can't even compile stuff any more because "no space left on device" m( 02:05
oh, that could have been /tmp that's full, actually
663.4 MiB [##########] core_setting.speshlog.txt 02:06
oh well!
github.com/Overv/vramfs - heck yeah 02:10
github.com/acozzette/BUSE - cool! 02:23
05:51 synthmeat left 05:53 synthmeat joined 05:54 synthmeat left, synthmeat joined 06:32 Altai-man_ joined 07:00 domidumont joined
nwc10 good *, #moarvm 07:10
MasterDuke vramfs looks pretty cool. unfortunately i only have 2gb on my video card. just another reason to upgrade it i guess... 07:19
07:58 zakharyas joined
MasterDuke i just don't quite understand it. i can change names of variables in a particular function and see that reflected in the output of the plugin 08:00
nwc10 .tell brrt \o 08:01
tellable6 nwc10, I'll pass your message to brrt
MasterDuke but if i add an `if (1) { <do something> }` to the function, the entire function is skipped by the plugin
well, that's not quite true. the function is processed, but it doesn't have any basic blocks anymore? 08:02
oh! if i add a print for each bb/ins/cf/etc i do see the MVM_exception_throw_adhoc 08:04
ah, i think it's not seeing a GimpleReturn when there's an MVM_exception_throw_adhoc 08:07
yep 08:14
08:27 sena_kun joined 08:29 Altai-man_ left
jnthn yawns 09:20
sena_kun jnthn, morning! 09:39
jnthn morning o/ 09:41
Ah, coffee starts to work, soon I might have a brain... 09:42
10:26 Altai-man_ joined 10:28 sena_kun left 10:56 Kaiepi joined
nine MasterDuke: well MVM_exception_throw_adhoc is MVM_NO_RETURN ;) 11:18
nine could use some of that coffee that jnthn mentioned
nwc10 shops are open 11:21
(today)
MasterDuke nine: heh, except that i removed that annotation from all the MVM_exception_* function! 11:32
11:37 zakharyas left 12:09 squashable6 left 12:11 squashable6 joined 12:27 sena_kun joined 12:28 Altai-man_ left
timotimo so it figured out by itself that it does a longjmp? 12:55
MasterDuke i guess. but the throw is not the only exit route. it can also return normally 12:57
timotimo mhm
MasterDuke github.com/MoarVM/MoarVM/blob/mast...#L195-L210 is what i've been modifying. i added `if (num_graphs > 10000) { MVM_string_say(tc, str); MVM_dump_backtrace(tc); MVM_exception_throw_adhoc(tc, "old_buf %d", old_buf[0]); }`, and the GimpleReturn is there, but no output about anything in that if block 13:00
if i change it to `if (1) { ... }`, then the GimpleReturn isn't there 13:01
13:17 zakharyas joined
MasterDuke gist.github.com/MasterDuke17/eb9c8...8dd36aa041 updated with the gimple graph for turn_32bit_into_8bit_unchecked(). the block in the if doesn't go to the exit 13:35
maybe i'll try just removing the abort() (and longjmp()?) from MVM_exception_throw_adhoc_free_va for the purposes of this analysis 13:37
huh. i commented out the panic_unhandled_ex(), abort(), and longjmp() calls in MVM_exception_throw_adhoc_free_va. there's a warning that a `‘noreturn’ function does return`, but that block in turn_32bit_into_8bit_unchecked still doesn't point to the exit 13:45
but why does it complain that MVM_exception_throw_adhoc_free_va returns? i don't have a return. and why does it think it's noreturn anyway, i also removed the MVM_NO_RETURN from it? 14:03
14:04 Kaiepi left
nine what's left? 14:09
tellable6 2020-05-20T12:29:34Z #raku-dev <Xliff> nine I think it was one of your bug fixes, that again required the use of a full directory lock. I think it was the .repo-id situation you fixed in f5ce80e1a6d60a6a51a898da85f3100bb088dfb4
linkable6 (2020-02-13) github.com/rakudo/rakudo/commit/f5ce80e1a6 Fix concurrency issue with re-checking a precomp file's dependencies
14:09 Kaiepi joined
MasterDuke nine: what do you mean? 14:09
timotimo MasterDuke: it could be a declaration vs implementation thing 14:11
that no return was put in two places?
MasterDuke oh
nine yeah, what's left of it after your removals? both in the .h and .c 14:12
MasterDuke huh. removed it from the declaration also, same error
i'll put a diff
gist updated 14:13
nine Thought so... there's still the MVM_NO_RETURN_ATTRIBUTE in the .h 14:16
timotimo ah, yes, there's two places where it could go, and to make it work on all compilers, we have to put it in twice
nine MVM_NO_RETURN_ATTRIBUTE is __attribute__((noreturn)) on gcc and that's what's actually effective. MVM_NO_RETURN compiles to nothing there 14:17
MasterDuke removed those also. now i get a lot of `warning: control reaches end of non-void function` (no surprise), but i still get `In function ‘MVM_exception_throw_adhoc’:src/core/exceptions.c:881:1: warning: ‘noreturn’ function does return` 14:21
nine Btw. I've found it helpful to create a minimal .c file to test my plugin against. You just need to #include <moar.h> and can do everything you see in MoarVM's code 14:22
MasterDuke and the block in turn_32bit_into_8bit_unchecked still doesn't point to the exit
ah ha! 14:25
github.com/MoarVM/MoarVM/blob/mast...ash.h#L226 14:26
14:26 Altai-man_ joined 14:28 sena_kun left
MasterDuke huh. so now if i do `if (1) { MVM_malloc; MVM_exception_throw_adhoc }` my plugin finds it. but if it's `if (num_graphs > 10) { ... }` it doesn't process that block 14:38
Geth MoarVM/new-disp: cf9f6ccd45 | (Jonathan Worthington)++ | src/core/frame.c
Factor some bits out of frame invocation

This makes it a bit easier to follow, and will also reduce code dupe while we temporarily have two such code paths during dispatch refactors.		 14:58
MoarVM/new-disp: 3fd2bdbd64 | (Jonathan Worthington)++ | 14 files
Get the boot-code-constant dispatcher in place

Which is the entry point to writing bytecode from a dispatcher. For now, since we aren't storing the dispatch program, it doesn't actually fixate it, but otherwise it works out.
jnthn Now to make it eat itself... :) 15:06
Altai-man_ jnthn, circularity at its best or?
MasterDuke ha, my plugin did find at least one actual case. github.com/MoarVM/MoarVM/blob/mast...shot.c#L63 the `col` that's MVM_calloc'ed at line 44 isn't freed
jnthn Altai-man_: Yup, using the dispatch mechanism to provide the means for defining new dispatch mechanism. :) 15:07
timotimo wonderful!
Altai-man_ jnthn, good luck! 15:08
timotimo so you can dispatch while you dispatch, of course
MasterDuke github.com/MoarVM/MoarVM/blob/mast...tex.c#L11, github.com/MoarVM/MoarVM/blob/mast...dp.c#L315, github.com/MoarVM/MoarVM/blob/mast...ps.c#L263, github.com/MoarVM/MoarVM/blob/mast...loc.c#L30, 15:15
github.com/MoarVM/MoarVM/blob/mast...ode.c#L918 all seem suspect
nine MasterDuke: yep 15:19
timotimo fantastic 15:21
should we also run clang's static analysis on the codebase regularly? 15:22
MasterDuke isn't dogbert17 on a monthly or so cron? 15:24
kind of surprised it thinks github.com/MoarVM/MoarVM/blob/mast...hore.c#L33 is bad. it give the lhs of the malloc the name '_1', but the argument of the free the name '_4' 15:25
nine Well, the code will look like: tmp_1 = malloc(...); body->sem = tmp_1; tmp_4 = body->sem; free(tmp_4); That's just how it decomposes complex expressions 16:06
MasterDuke hm. (luckily?) it doesn't find all that many instances, so manually checking isn't really a problem 16:07
16:09 patrickb joined 16:27 sena_kun joined 16:29 Altai-man_ left
[Coke] trying to track down my "abort trap 6" on OS X - no luck, but here are some small issues a valgrind run mentioned: gist.github.com/coke/d7e2a782cdc53...de1883c0ca 16:35
Geth MoarVM/new-disp: 9271443170 | (Jonathan Worthington)++ | 18 files
Stub in the boot-syscall mechanism

This provides a way to register such calls, and sets them up at startup. A call has an unchecked implementation body that will pull received args out without needing to validate them, along with metadata used to do the validation. A boot-syscall, when it's fully implemented, will on its first dispatch do these checks and set up the guards. The ultimate goal is that we can do standard guard elimination on these in spesh, then call the C function, providing a far more uniform interface for the VM interanls.		 17:11
timotimo time to rewrite some of the interanls! 17:12
jnthn Well, once it's done, yes 17:13
I also think we'll be able to JIT these far more uniformly also
timotimo aye
hm, will using syscalls for stuff like trigonometry ops make code a little bigger? will we only use the mechanism for stuff that's not as frequent, maybe? 17:14
jnthn yes, but are trig ops frequent? :) 17:15
(compared to others, I mean)
timotimo right, it was just the first thing that came to mind
jnthn But yeah, it's undecided how far exactly we'll go with this. 17:16
timotimo maybe some file and dir ops are good candidates, socket ops, too, perhaps? they may be interested in having the repr checked and then "devirtualized" as well
which the dispatch chain mechanism would now allow even without the jit
i think?
jnthn Hm, quite possilby, yes
timotimo mister worthington, how drunk is your typing today :) :) 17:17
jnthn haha
Didn't even have a drink today :P
Home time o/ 17:21
timotimo i thought "if we get our op number low enough we could go down to 8 bit for the op number!" but realized quickly that we do that for alignment purposes
jnthn Yes, we'd have to change a few other things if we want to do that. 17:22
timotimo MoarVM Thumb Instruction Format 17:23
maybe we recronym HAMMER for that, because hammer goes very well with thumb
17:56 Kaiepi left
Geth MoarVM: patrickbkr++ created pull request #1290:
Backport a change in libtommath to fix build on x86 Windows		 18:00
18:01 zakharyas left
MasterDuke this is my current list of allocating functions: 'MVM_malloc', 'MVM_calloc', 'MVM_fixed_size_allocate', 'MVM_fixed_size_allocate_zeroed', 'MVM_string_utf8_encode_C_string' 18:19
any others that would likely be called before an MVM_exception_throw_adhoc* ? 18:20
18:26 Altai-man_ joined 18:28 sena_kun left 18:54 camelia left, camelia joined 18:55 domidumont left
MasterDuke heh. i now have a longer list, but get a segv when making moarvm 19:01
19:25 zakharyas joined 19:43 camelia left 19:44 camelia joined 20:13 Kaiepi joined 20:27 sena_kun joined 20:28 Altai-man_ left 20:49 zakharyas left 21:30 Geth left, Geth joined 21:43 rypervenche left 21:46 rypervenche joined 22:26 Altai-man_ joined 22:29 sena_kun left 22:54 Altai-man_ left 23:51 patrickz joined 23:55 patrickb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!