01:17
unicodable6 joined,
quotable6 joined
02:57
ilbot3 joined
03:57
bloatable6 joined
10:43
domidumont joined
10:50
domidumont joined
11:46
committable6 joined
11:54
Ven`` joined
|
|||
nine | This is...odd. I've just managed for the first time to get a version up and running that actually eliminates the goto at the end of an inlined function instead of just replacing it by a no_op. The key was to move all 3 annotations (INLINE_END, FH_END and FH_GOTO) to the next instruction instead of the previous on removing the goto. | 13:06 | |
13:57
Ven`` joined
14:09
dogbert17 joined
14:14
bisectable6 joined
|
|||
nine | But moving INLINE_END and FH_END onto a non-inlined instruction obviously makes no sense | 14:29 | |
14:35
Ven`` joined
|
|||
jnthn | Are you sure it's not just FH_END that is the issue? | 14:35 | |
nine | I can try | 14:38 | |
jnthn: actually FH_END doesn't seem to matter. INLINE_END has to go on the next instruction instead of the previous | 14:42 | ||
14:47
squashable6 joined
|
|||
nine | With that rakudo's build succeeds, make test is successful and only a couple of spectests fail with dubious "Two terms in a row" errors. Would be nicer if it actually made sense though. | 14:50 | |
jnthn | Hm, I wonder if FH_END is a post or pre annotation | 15:27 | |
16:36
zakharyas joined
|
|||
nine | What does that mean? | 16:38 | |
timotimo | whether the instruction it's attached to is considered inside or outside the area | ||
16:39
zakharyas joined
16:40
zakharyas joined
17:00
zakharyas joined
17:23
coverable6 joined,
benchable6 joined
18:05
zakharyas joined
18:24
Ven`` joined
18:40
releasable6 joined,
greppable6 joined,
reportable6 joined
18:41
statisfiable6 joined,
nativecallable6 joined
|
|||
samcv | good * | 19:02 | |
19:10
zakharyas joined
19:12
zakharyas joined
19:15
zakharyas joined
|
|||
lizmat | samcv o/ | 19:42 | |
20:50
evalable6 joined
20:52
Ven`` joined
21:58
Ven`` joined
|