freenode/#sicl - IRC Chatlog
Search
4:02:51
beach
Are there any reasons to disallow raw data in HIR other than making it easy (or possible) for the type inferencer to do its job?
4:04:04
beach
I can see that the type inferencer could not do much if it found an instruction with a raw input and a Common Lisp datum output, other than inferring the type T of the output.
4:05:19
beach
But what if lexical locations had a type as well, indicating that the run-time value must be a subtype of that type.
4:07:39
beach
Then there would be no harm in exposing address calculations in HIR. For example, the AREF instruction could be turned into instructions for loading from memory, as long as the ultimate Common Lisp datum were marked with the right type.
4:09:18
beach
Argument parsing needs raw data, and I would like to introduce argument parsing early, right after HIR generation, so that HIR transformations will be able to hoist FDEFINITIONs and such.
4:10:08
beach
But if this introduction makes type inference impossible, it is definitely a bad idea.
4:16:26
beach
Clearly, if the exact type of an input to an instruction can influence the exact type of an output to that same instruction, we would not want to replace that instruction with a sequence of instructions with a raw intermediate datum. Because then the type inferencer would be stuck with the most general type of the output. But for some instructions like AREF, the type of the output is determined only by the element type of the array.
4:18:07
beach
But I am not concerned with AREF right now, but with arguments. And we can't know the types of the arguments to a function, so in that case, we could allow for raw data and just mark any Common Lisp output datum to have type T.
4:18:57
beach
If I see no objections to this idea, I will continue my thinking in that direction, rather than the previous idea of introducing special instructions for argument parsing.
4:33:08
beach
Here is a thing though. It doesn't make much sense to assign a type to a lexical variable unless it is SSA.
4:34:53
beach
So would it be a good idea to have SSA-LEXICAL-LOCATION as a subclass of LEXICAL-LOCATION and only have a type slot in the subclass?
4:35:53
beach
I mean, many variables, especially temporaries, are known to be SSA when they are created.
5:42:39
beach
There is another advantage to typed SSA locations. The type inferencer must keep a mapping from a cross product of lexical locations and program points to types. But for SSA locations there is a single program point needed, so the type inferencer can use the slot in the lexical location for SSA locations. This access is very likely faster than the general one.
7:53:04
beach
I think I'll just introduce raw data and register locations into HIR and we'll see what happens.
7:56:35
heisig
beach: What do you mean by 'raw data' and why is that necessary to introduce argument parsing on HIR? (Sorry if I missed that explanation in the logs)
7:58:41
beach
I can wait and introduce it when all HIR transformations are done and I translate to MIR.
8:00:12
beach
But hoisting is a HIR transformation, so then it is too late to introduce the min MIR.
8:04:21
heisig
If I understand correctly, these are only needed to reference a function's arguments.
8:08:24
heisig
But all these things could also be achieved with the current HIR instructions. The only thing that is not possible as of now is to determine the number of arguments, and to access the Nth argument.
8:10:51
heisig
One idea would be to introduce a special object - let's call it 'argument-pack' - and two instructions ARGUMENT-PACK-LENGTH and ARGUMENT-PACK-REF.
8:11:57
heisig
Or, one could rely on the fact that the stack is an implicit argument, and just provide the instructions ARGUMENT-LENGTH and ARGUMENT-REF.
8:12:00
beach
I need to move the arguments from their locations at function entry, to stack locations with lower addresses in order to make room for lexical locations.
8:13:24
heisig
For that, one could add a third instruction FINALIZE-ARGUMENT-PARSING that frees the arguments on the stack.
8:19:55
heisig
In terms of aesthetics, I'd prefer an abstraction like argument-packs to having raw stack manipulation in HIR.
8:21:34
heisig
Of course, I can only make such remarks because I know you would detect bad advice and ignore it :)
8:24:20
beach
I agree that it would be preferable to find some abstract solution. I just haven't come up with one yet.
11:28:41
beach
With only two specific instructions, COMPUTE-ARGUMENT-COUNT-INSTRUCTION and ARGUMENT-INSTRUCTION.
11:29:28
beach
The second one takes a fixnum input (constant or lexical) and has the argument with that number as its output.
11:30:17
beach
I also need an instruction for checking that there is an even number of remaining arguments, so I will introduce FIXNUM-ODDP-INSTRUCTION and FIXNUM-EVENP-INSTRUCTION to HIR.
11:30:48
beach
And I think I'll add the specific ones to HIR as well, in case some implementation would like to use them.
11:31:59
beach
This solution won't express moving the arguments, but that can be done in MIR, because there are no function calls required to do that.
11:35:31
heisig
I'm glad to hear that. It would have been really awkward to have HIR code manage the placement of entities on the stack.
11:36:58
heisig
Now we only need to make sure that the argument parsing code does not clobber the arguments or their count.
11:37:07
beach
Also, aside from the exact error message to be generated for foo few arguments, for too many arguments, and for an invalid keyword argument, the code is standard, so other implementations can use it.
11:40:55
Bike
well, that would be good anyway. that's a hir to mir kind of transformation, i would think
11:42:03
beach
Let's see, integer division between two fixnums is always two fixnums (quotient and rmainder)?
11:45:58
beach
Let me consult the Common Lisp HyperSpec and convince myself that they all, when given two fixnums, result in two fixnums.
11:53:15
Bike
what? i mean, yeah, fixnum divide seems good to me. maybe just have the rounding as a flag in it instead of having four instructions.
11:55:57
no-defun-allowed
Constant Variable CALL-ARGUMENTS-LIMIT: http://www.lispworks.com/documentation/HyperSpec/Body/v_call_a.htm