freenode/#clasp - IRC Chatlog
Search
14:43:30
Bike
karlosz: am i seeing correctly that as of yet, local calls still always return multiple values?
15:11:31
Bike
seems like it should be pretty easy to merge duplicate code just before a branch merge but we'd hit llvm's problem with multiple source infos
15:14:23
Bike
note to self do change the runtime so that unwind return values are sent through the exception object so we can save some multiple value save load stupidity
15:21:10
Bike
with known values, we could probably allocate stack space in the outer function, and stick the stack pointer in the continuation so the inner functions can mutate directly with those weird intrinsics
15:31:51
Bike
I suppose we could heap allocate space for the multiple values, unwind passing a pointer to that space, extract the values, and then free the space
16:13:34
drmeister
We should plan to improve clasp's compiler performance by a factor of 5 in four stages, with each stage increasing performance by 50%.
16:19:19
drmeister
I misspoke - not what they are doing - but this showed up in Hacker News: https://news.ycombinator.com/item?id=24837309
16:20:10
drmeister
To be fair - they used an equivalence symbol but I couldn't figure out how to generate it.
16:21:38
drmeister
There is some good advice in that post "Enhance compiler to generate superior machine code." We should be doing this!
16:22:35
drmeister
Good - because if you were degrading the compiler to generate lousy code I'd say stop and do this other thing.
16:37:52
Bike
like, if we have (if cond (done thing) (loop ... finally (return (done thing2)))), we can rewrite it as (done (if cond thing1 (loop ... finally (return thing2)))), but then the source location of the call to done is ambiguous
16:48:55
karlosz
Bike: you are quite right that i did not do anything special with return value conventions with local calls
16:50:07
karlosz
it would be really nice if we could do fast returns, but it seems involved given llvm. maybe you have a better idea how to do it?
16:50:21
karlosz
i don't think this really requires cleavir changes, this is purely a backend thing.
16:51:21
Bike
i figure local-call might have separate outputs to indicate it returns two object values, or whatever
16:51:46
Bike
since erasing multiple-to-fixed and fixed-to-multiple in the backend would be kind of annoying
16:54:08
Bike
i mean, i think it's fine, but the only transform we do with it now is deleting a f->m m->f when interpolating
16:54:36
Bike
i figured returni would take multiple inputs, and local-call would take multiple outputs, and for correcntess they'd have to correspond
16:54:40
karlosz
it would be great if the backend could choose the representation, or at least not in BIR, kinda like how the calling convention is chosen in the backend
16:59:15
Bike
cleavir2 doesn't have mv locations at all, but instead it assumes there's a global mv location, which is modified by the corresponding instructions
17:01:31
Bike
what i'm imagining is that we'd start out with a given function ending with f->m, and the calls to it having an m->f after them (if that's how they're used)
17:01:52
Bike
and ideally it would work similarly with cast instructions, so that local calls could return unboxed floats directly and such