|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| jnthn | tbh, the idea was that we'd not need to JIT them, because in hot-path code they'd tend to be replaced anyway | 00:04 | |
| (by sp_getarg_*) | |||
| It'd be worth looking at why we're ending up with them left behind in optimized code, and seeing if we can do something about that | 00:05 | ||
| In that even if we JIT them, they're still full of bound checks and stuff | |||
| timotimo | i think perhaps the argument specialization code is too eager to quit when it hits something it can't perfectly handle; like when it gets a NativeRef and wants to param_rp_i it or whatever that was that i found the other day | 00:15 | |
| jnthn | Ah, NativeRef... | 00:18 | |
| Well, it quits when it can't be sure it'd do the correct thing, which is worse than wrong thing + crash :) | |||
| But yeah, worth checking if it's getting upset over nativeref, 'cus in theory that's an easy fix | |||
| timotimo | MasterDuke: if you could tell us where you found the param_op_* being left over, that could probably help us figure out what's going wrong | 00:19 | |
| ugexe | i think it was from this perl5/perl6 benchmark | 00:22 | |
| for (1..100000) { ((join( "", (!($_ % 3) and "Fizz" or ""), (!($_ % 5) and "Buzz" or "") ) or $_), "\n") for 1..20; } | |||
| 15:59:25 <MasterDuke>join in src/core/Any-iterable-methods.pm6:2143 isn't getting jitted becuase of param_op_o | |||
|
00:28
lucasb left
00:32
dalek left
00:33
Geth left
|
|||
| MasterDuke | correct | 00:49 | |
|
06:39
synopsebot left,
p6lert left,
dalek joined,
Geth joined,
p6lert joined,
synopsebot joined
06:52
brrt joined
|
|||
| brrt | dogbert17: a document like that one, yes, except that I already read that one and couldn't find it | 06:57 | |
| but I may have misread | |||
|
07:12
domidumont joined
08:56
Geth left,
Geth joined
09:21
zakharyas joined
09:22
brrt left
09:23
robertle joined
10:00
brrt joined
10:35
robertle left
10:48
robertle joined
11:00
robertle left
11:03
robertle joined
11:11
domidumont left
11:13
scovit joined
|
|||
| scovit | brrt: I think that the calling convention for that is RDX:RAX (< 16 bytes) or stack in SysV and RAX (< 8 bytes) or stack in Win64 | 11:17 | |
|
11:28
robertle left
|
|||
| scovit | brrt: but now I am discovering that on windows it seems a bit more complex than that, if on the stack, the caller need to make the space, pass the address in rcx, and than gets back the address of the result in rax | 12:08 | |
| brrt | scovit: I think so too... but I'd prefer to see it in writing, is the thing :-) | 12:25 | |
|
12:33
zakharyas left
12:39
robertle joined
12:52
brrt left
13:14
brrt joined
13:45
domidumont joined
13:57
zakharyas joined
13:58
domidumont left
14:19
lucasb joined
15:48
domidumont joined
16:16
domidumont left
16:29
brrt left
17:16
domidumont joined
17:28
AlexDaniel left
17:43
patrickb joined
18:21
zakharyas left
18:43
patrickb left
19:21
patrickb joined
|
|||
| scovit | brrt: Ok I found, docs.microsoft.com/en-us/cpp/build...er-passing for Win64 | 19:49 | |
|
19:51
domidumont left
|
|||
| scovit | www.uclibc.org/docs/psABI-x86_64.pdf pag 22 for SysV | 19:51 | |
| it is relevant the MEMORY type, for objects that do not fit RDX:RAX, same for windows if it does not fit RAX | 19:52 | ||
| in both case the space on the stack is caller provided | |||
|
20:31
patrickb left
20:32
patrickb joined
|
|||
| Geth | MoarVM: patzim++ created pull request #1086: Fix default target on nmake |
21:42 | |
|
23:44
nebuchadnezzar left
|
|||