freenode/#sicl - IRC Chatlog
Search
5:45:21
beach
Today, I think I need to finish the paper. But then, I also need to figure out what I did for argument parsing in MIR so that I know how to start off the register allocator.
6:04:41
splittist
beach: two small comments on your paper. You say a few things about the cost of operations on modern processors - perhaps there is a need for an example and/or cite (not least so future generations can decide if the technique still makes sense in the context of the processors they will use). Second - you might want to briefly say what a 'function object' consists of (since it's not the name, environment or code).
7:48:15
beach
Well, frodef made me put in the phrase about indirect branches being significantly more expensive than direct branches, and that is probably true, but I can't find anything to cite for that information.
9:21:35
beach
New version of the paper here: http://metamodular.com/SICL/call-site-optimization.pdf now citing references for modern processors, and explaining the contents of a function object.
9:28:12
beach
So this technique avoids 1. the indirection associating the name with the function object, 2. the indirection for accessing the entry point from the function object, and often 3. the access of the static environment, since frequently global functions have empty static environments.
9:28:42
beach
Given that unconditional direct jumps are really nearly free, we can't possibly lose here.
9:29:45
beach
And of course, as I explained, many more indirections are involved for the specific case of SICL, and all those indirections are avoided as well.
12:09:26
no-defun-allowed
Just to check before I embark on it tomorrow, can you re-upload ELS submissions?
13:13:35
beach
heisig: no-defun-allowed was wondering whether it is possible to re-upload ELS submissions.
13:14:15
beach
But I guess you will block that possibility as soon as the referees have been assigned their papers.
13:20:45
heisig
Also, re-uploads were never forbidden in the last years, not even during the bidding phase. I know that, because I used that feature frequently.
13:23:16
beach
Yes, but it becomes problematic. If the referee refers to a particular paragraph and that paragraph has then moved or been deleted or altered, then there will be a communication problem.
13:25:58
heisig
Don't hesitate to contact me in case there are any further problems or questions regarding the submissions.
13:26:29
heisig
This is very valuable for me, because I cannot change to the 'author' role myself. So I don't see what the authors see.
14:04:17
beach
I think to the EDU calculation I should add some "probability" that the next use of a variable is going to be after a function call. If, at a particular program point, that probability is zero, then any register can be assigned to it. The higher the probability, the more likely it is that a callee-saves register will be assigned to it, or that it will be spilled.
14:38:47
beach
One complicating factor that I took into account in the description of the register allocator in the SICL specification was information about whether a variable is next needed in a specific register. I put that in for the function-call protocol. But with call-site optimization, it doesn't matter what register is used, or even whether a register is used. So I am going to take that out.
14:41:03
beach
And, by the way, the call-site optimization technique means that 1. Most of the time, no particular register needs to be reserved for argument passing and 2. That any register can be used to pass arguments, so we can have many more arguments passed in registers than with a small and fixed set of registers reserved for this purpose.
14:41:33
beach
The more I think about it, the more I am convinced this technique is going to be dynamite.
14:47:13
beach
Let's see, instructions such as MOV just moving one register to another register ought to be very cheap, because of things like register renaming, right?
14:48:36
beach
If so, that means that in a loop, as long as variables are kept in *some* register, it is OK if the back arc has to shuffle some registers around.
14:50:31
beach
I am saying that, because another reason I had for the information about a variable needed in a specific register was for back arcs, where a register had already been assigned to a variable.
14:52:17
beach
But if a variable is needed frequently in a loop, it is likely to stay in the register it was first allocated to. And if it is cheap to occasionally get it wrong, then I am not going to complicate things by taking that possibility into account.
15:08:32
beach
There! Now the description is sufficiently small that there is some hope to get the implementation right.