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.