[09:13] *** lizmat joined [09:35] i'm finally starting to recover from a pain that's been plaguing me for a week+, so i can finally think a bit more clearly about the code, but i'll be AFK all day; since we can look up lexicals at spesh time, why don't we look up ::?CLASS and see if it matches the type facts we have for the first argument? does that make sense? and if it doesn't match, we don't specialize getlexperinvtype to become [09:35] a constant, or we take the "speculatively make it a constant but do the lookup anyway and guard" thing from the current pull request [09:35] ::?CLASS isn't necessarily the right one though, could be we have to check ::?ROLE instead or something else [09:35] I still haven't looked at the code at all for this [09:47] *** lizmat left [09:57] ok i remember now why that wouldn't work; the getlexes that we use getlexperinvtype for are all dependent on looking up their lexicals through closures, so we actually can't look the things up statically at spesh time, we have to rely on values we see in the spesh log [09:58] if we can't easily put a "we're invoking this not with an invocant, just with a boring regular object argument" bit of information somewhere, we may have to change where the compiler emits getlexperinvtype; IIRC it's just getlex with some special logging and semantics when spesh sees it [09:59] so it should never be wrong to just put getlex instead of getlexperinvtype, just less opportunity for optimization [10:00] the compiler probably has a much easier time figuring out if the first argument to the callable it's compiling at the moment is related to the current "invocant type" or not [10:00] we could also literally introduce a new op that also takes the type, or value, of the current invocant, i.e. what's in "self", so that spesh can log and/or check that at spesh time too [12:38] Would you like me to take a look at that? I'm very unfamiliar with the levels above spesh. Any suggestions for where to look first? (I want to learn the codebases but it's more than a little daunting I will admit :D) [12:43] My instinctive thought would be to have the metadata emit a bit to say that ?::CLASS == arg0, I'm just not sure what that would cost. That way if true we could specialize on invocant and if not, use the indexed pointer as a fallback less aggressive specialization. [12:44] It seems knowable at compile time but my knowledge of Rakudo and the AST is minimal. [12:46] Alternatively the postfix should lower to the same AST as the block. [12:46] It feels unintuitive that one optimizes better than the other one. [16:54] *** [Coke] left [18:27] *** lizmat joined [18:51] *** [Coke] joined [19:29] I assume we can't just inline the block because it sets $_ and $_ is dynamically scoped? [19:30] $_ *was* dynamically scoped in 6.c, but no longer in 6.d [19:31] m: use v6.c; dd $_.VAR.dynamic [19:31] rakudo-moar 8bb460f2a: OUTPUT: «Bool::True␤» [19:31] m: use v6.d; dd $_.VAR.dynamic [19:31] rakudo-moar 8bb460f2a: OUTPUT: «Bool::False␤» [19:31] *** lizmat left [19:32] on the other hand, lexical-to-local-lowering should already be able to handle $_ regularly for the case of a `with True { ... }` or `... with True` [19:33] actually, how do we handle $_ at the moment with a postfix with or postfix if? can we inline that form properly? [19:36] a difference between `with True { ... }` and `... with True` is that one logically introduces a scope that is also visible to introspection with OUTER:: and what-not [19:43] https://godbolt.org/z/KjeG7Exfr btw did you all already know about this [20:40] Postfix with is the case on the ticket, arg0 ends up as $foo in 'with $foo' so if $foo is an object with a known type, it gets specialized on $foo (which doesn't work when it's a role method being composed by a class -- the class lookup uses the original calling class). [20:41] so any call to the method with Str (for example) looks up the specialization against the wrong role-composed class. [20:42] If you call with $foo as an Int, it works fine because that isnt specialized yet [20:45] have you already looked into the spesh log emitted for the test code? [20:46] I did but it was the day I filed the ticket so I've forgotten most of it :D [20:46] also before some more golfing I think? [21:18] Voldenet did the golfing IIRC. I just added the Int test to try to falsify my theory.