These are chat archives for dropbox/pyston

20th
Mar 2015
Travis Hance
@tjhance
Mar 20 2015 04:20
@kmod (or anybody) I have a question about how OSR works
so from the debug output, it looks like it creates this OSR function
define void @"<module>_e1_osr4_0"(%"class.pyston::Box"* %"prev_#iter_0x405f020") {
what is prev_#iter_0x405f020?
Also, why is there only one argument? In ast_interpreter there’s this line
return partial_func->call(std::get<0>(arg_tuple), std::get<1>(arg_tuple), std::get<2>(arg_tuple), std::get<3>(arg_tuple));
and I’m confused because there it’s passing 4 arguments
isntead of just the 1 implied by the llvm ir function definition
Travis Hance
@tjhance
Mar 20 2015 05:01
WAIT
I’m really dumb
it’s call that takes 4 arguments
i understand, I think
Kevin Modzelewski
@kmod
Mar 20 2015 05:32
oh, yeah I think arg_tuple in this case will only have 1 element
and the last 3 arguments will just be bogus data
but not actually get read by the callee :P
Travis Hance
@tjhance
Mar 20 2015 05:33
yeah I figured out what was going on
the (Box*)is_defined where is_defined is a bool also threw me through a loop
but I figured out what was going on there, as well
Kevin Modzelewski
@kmod
Mar 20 2015 05:34
do you remember what the for_call argument does?
is it just an optimization hint that is ok to ignore?
Travis Hance
@tjhance
Mar 20 2015 05:34
yes
er
yes
it is okay to ignore
Kevin Modzelewski
@kmod
Mar 20 2015 05:35
ok, good to know
I'm trying to change some of our getattr behavior
well, mostly refactor it
Travis Hance
@tjhance
Mar 20 2015 05:36
I’m trying to figure out how to add a FrameInfo* to the list of arguments to the OSR
what would you recommend?
it seems like the most natural thing is to create a FRAME_INFO compiler var type, since entry->args is a map of compilervars
Kevin Modzelewski
@kmod
Mar 20 2015 05:38
that sounds reasonable to me
Travis Hance
@tjhance
Mar 20 2015 05:38
but that also seems like overcomplicating it a bit since compilervars are pretty complicated, right?
and we don’t really need any of the functionality other than that it gives an llvm type
Kevin Modzelewski
@kmod
Mar 20 2015 05:39
well, I guess you don't need to define a custom compilertype in order to pass the value through
you could just pass it as an UNKNOWN and then change the type based on the name
(since the type will probably get converted to UNKNOWN anyway in order to be stuffed into the array)
Travis Hance
@tjhance
Mar 20 2015 05:40
I thought of that too but it seemed hacky
Kevin Modzelewski
@kmod
Mar 20 2015 05:40
you can also check out the GeneratorType
which we use for the generators
if you don't actually use any of the functionality there's not that much you actually need to add
Travis Hance
@tjhance
Mar 20 2015 05:40
right
okay good idea
Kevin Modzelewski
@kmod
Mar 20 2015 05:40
but it gets you that extra bit of type safety
Travis Hance
@tjhance
Mar 20 2015 05:41
what are drop and grab, out of curiosity?
Kevin Modzelewski
@kmod
Mar 20 2015 05:41
remnants of our old refcounting system
Travis Hance
@tjhance
Mar 20 2015 05:42
we used to have a refcounting system?
Kevin Modzelewski
@kmod
Mar 20 2015 05:42
which in theory might end up being useful if we want to do precise stack scanning, but I think have just bitrotted
yeah pyston used to be 100% refcounted :)
Travis Hance
@tjhance
Mar 20 2015 05:42
that must have been a long time ago
I think even when the pyston announcement came out, the README talked about a conservative collector
Kevin Modzelewski
@kmod
Mar 20 2015 05:43
yeah looks like that was changed before it got open sourced