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