libera/#sicl - IRC Chatlog
Search
2:13:15
moon-child
i think there is in general a sentiment that there shouldn't be too many such things (vs open-coded algorithms in some slightly higher-level intermediate representation), because they are not optimisable
2:17:49
Bike
i don't think SICL includes any assembly at this time, and as far as i understand the plan, it won't
2:18:41
Bike
it might have something like SBCL VOPs, but those aren't really aseembly routines so much as they are things the compiler can use to construct assemblies
2:24:48
moon-child
so you are looking for the assembler? It is https://github.com/robert-strandh/cluster
2:49:12
hayley
There is also https://github.com/robert-strandh/SICL/tree/master/Code/Compiler/MIR-to-LIR which selects instructions and performs register allocation.
2:52:21
hayley
There are some more or less hard-coded instruction sequences, like for calling an unnamed function, as suggested by plural "kernels".
3:29:38
beach
And, as you pointed out, if the callee has a single location for every variable, you can get the original argument instead of a modified one.
3:31:35
beach
The call-site descriptor can also be used by the garbage collector in that it contains a bitmap of stack locations to be traced.
3:48:01
beach
Bike: I am also wondering how easy it would be to adapt Cleavir2 so that it uses call-site optimization. But I know it's probably late for you, so no rush.
3:58:08
Bike
as to call site optimization... i have not thought deeply about it, but let's see. first off instead of doing a global call you want to jump to the fragment (i forget the term, the replaceable bit of code that does the work). that seems mostly like a matter for the translator, and wouldn't need to be reflected in the IR until very late
3:59:08
Bike
And secondly you want the information from the IR (e.g. derived types of the arguments) to be made available to the call site manager
4:00:01
beach
I guess you are right that it is mostly a concern for later phases, so it should be OK.
4:00:32
Bike
part of my plan with the wiki document i linked a while back was to make analysis information like that available in a more uniform way, so hopefully that could facilitate call site optimization
4:01:16
Bike
There is one other thing, which is that i see here in 16.6 the idea that a lexical or anonymous function could be call site managed
4:01:52
Bike
Cleavir goes through some effort to facilitate eliminating calls to such functions, or having them use idiosyncratic calling conventions, etc., that might not play well with call site management
4:03:23
Bike
I'm not sure I see the advantage of call site management for a lexical function, since it's by nature unchanging, but I haven't thought about it
4:04:25
Bike
Another quirk might be in the "rtypes" i mentioned in the wiki document - like passing unboxed values around. In addition to knowing the realization of a value (like the location in a register, etc.) the call site manager would definitely need to know if an argument is going to be a boxed object versus an unboxed float versus whatever
4:07:04
Bike
hrm, call site optimization could throw some complication into representation selection... but that algorithm needs a lot of work anyway
4:09:24
Bike
The selection of how values should be represented, like boxed versus unboxed and so on, and where "casts" between those representations need to be introduced
4:11:29
beach
I was wondering about Cleavir 2 mostly because the plan is still to abandon Cleavir 1 at some point. Nothing urgent of course. I am still working on bootstrapping.
4:11:56
Bike
very basic example of what i'm thinking of: If you have (+ a-double-float 4d0), with my basic algorithm, the 4d0 will be unboxed, but with (print 4d0), it would be boxed since it has to do a general call
4:12:22
Bike
But with call site optimization, you could have a call site for print (or whatever other function) that is actually prepared to deal with an unboxed double, so that might be the more efficient representation
4:14:45
Bike
Unfortunately I don't really have a good idea of the best algorithm to use. It can get pretty involved, I think. E.g. if you need to insert a boxing operation, it would be better not to do it in a hot loop if possible, so then you need to apply LICM to this pretty low level concern
4:15:25
Bike
And yeah, I understand you've been working on bootstrapping, and of course you wouldn't want to switch horses midstream
4:17:38
beach
What the trampoline snippet does is dictated by the callee. The caller must be prepared to satisfy the needs of any callee, since the callee might change later.
4:18:44
beach
There would not be a situation where the caller keeps only unboxed values that it needs to pass as arguments to a potentially unknown callee.
4:20:24
Bike
Yeah, what I'm imagining is a situation where the compiler is for whatever reason pretty sure that the function will be amenable to unboxed numbers, so it's willing to eat the loss of having to re-box in the rarer situation where it isn't.
4:21:35
beach
Sure, I can imagine such a situation. But I suspect I have not yet figured out all possibilities for call-site management.
4:22:24
beach
So far, I have considered only situations where the callee can change arbitrarily at some later point.
4:25:05
Bike
Oh, I guess with the results there is also a little concern. You could have a situation where the result of a call is always used in a context where an unboxed double would be better (e.g. (+ (the double-float (f)) another-double)). In that case the compiler would want to assume the result of f is unboxed, and the call site would either do something naturally resulting in an unboxed double, or type check and
4:25:37
Bike
So I guess I'd need to consider calls with unboxed results, which I don't do currently.
4:26:26
Bike
But this is all in the realm of optimizations rather than anything that would actually _need_ to change for a call site manager to work with Cleavir