freenode/#sicl - IRC Chatlog
Search
19:38:59
Bike
but this wouldn't be like the old multiple-to-fixed since the number of values is known
19:43:49
Bike
still, i think this is the main thing slowing the mirtype branch. i guess the alternate would be doing it at mir level... might as well try that i suppose...
22:10:17
Colleen
karlosz: Bike said 4 hours, 39 minutes ago: what if we introduce multiple-to-fixed in meta-evaluate? it seems simple to have meta-evaluate collapse (mv(-local)-call f known-values...) to a call and then try to interpolate again
22:10:18
Colleen
karlosz: Bike said 3 hours, 49 minutes ago: as opposed to leaving things as mv-calls all the way to mir level, i mean
22:23:28
Bike
well, it's mostly just a question of organization. i like how the post-bir translation layer can be pretty straightforward now, just working on individual instructions. complex use of inferred types would make it a lot more involved.
22:23:56
Bike
but i already have the bir-to-bmir bit doing "rtype" coercion stuff, so i guess putting it in there would be fine
4:52:21
no-defun-allowed
Looking at the bindings of the most recent CST-EVAL call in the backtrace, I spotted that the problematic function is the macro function for CALL-METHOD in WRAP-IN-CALL-METHOD-MACROLET, and the undefined lexical variable shares a name with the only lexically bound variable (that ARGUMENTS-nnn name that WRAP-METHOD-COMBINATION-FORM generates).
4:54:32
beach
I am still surprised though. If the HIR evaluator manages to execute the code, I can't see how there can be a problem in HIR.
4:56:04
no-defun-allowed
Yes, it took me a while to figure out what was going on (which isn't your fault). It's as if the usage of that closed-over variable isn't converted properly, but that would indeed be reflected in HIR surely.
4:57:44
beach
In other words, if everything works when you turn off HIR-to-MIR, then it is hard to imagine that the problem would be in HIR.
5:00:37
beach
Aha. Then there is probably something wrong in HIR-to-MIR, because nothing is using MIR other than MIR-to-LIR.
5:03:45
no-defun-allowed
Now I remember that the information in the environment object for that variable referred to a lexical location, and I think it was the same location.
5:06:53
beach
It is hard to believe that a single source function would be the origin of a problem like this, because that would mean that this function is the only one using a particular HIR instruction class, and that the HIR-to-MIR processing of that instruction class would be buggy.
5:34:00
beach
If there is an uninitialized lexical location in HIR, that must mean that the HIR evaluator never executes the instruction that uses it.
5:36:12
beach
Some AST classes and instruction classes are uniquely used by some methods for arithmetic.
5:36:42
no-defun-allowed
It is an assignment instruction, which was probably produced in order to call WRAP-IN-CALL-METHOD-MACROLET.
5:38:19
beach
It is hard for me to imagine that it would have something to do with that function specifically, because it seems to me that this function is used everywhere, so then no generic function would work properly.
5:42:30
beach
It is much more likely that it has to do with the translation of some specific AST class to HIR. An AST class that is used only in very specific situations, like floating point stuff.
5:42:47
beach
Because floating point stuff is never executed during bootstrapping. It is only translated.
5:43:13
beach
So if you see a problem in translation but not in execution of HIR then that's what I suspect.
5:46:04
no-defun-allowed
Nothing sticks out as particularly rarely executed. Maybe MACROLET, but that is about it.
5:47:04
beach
None of the methods having to do with floating point (for instance) on the arithmetic functions are ever executed.
5:47:25
no-defun-allowed
Here is the test function, and when it is run: <https://github.com/no-defun-allowed/SICL/blob/master/Code/Compiler/AST-compiler/ast-compiler.lisp>
5:50:26
no-defun-allowed
I can't think of any features that would be used as part of satiation in general which wouldn't also be used elsewhere.
5:53:01
beach
So do you see my reasoning here? There is an uninitialized lexical location in HIR. That means that the code is never executed by the HIR evaluator; only translated to MIR and then LIR. So then it can't be a problem with any general mechanism like calling methods. It has to be something that is loaded into the system, but never executed.
5:53:36
beach
What you could do, for instance, is you could remove some loads of arithmetic functions, even all of them.
5:56:01
beach
It could be that the information about the lexical locations is not always up to date.
6:07:24
no-defun-allowed
That variable is still undefined before any transformations, so I am still suspecting however AST-to-HIR handles MACROLET has broken something.
6:16:41
no-defun-allowed
The raw form from the CST makes me wonder if the ARGUMENTS-nnn variable should have been quoted, and bootstrapping succeeds (without any conversion past HIR) if I do that.
6:16:42
beach
That would mean that MACROLET is never used in code that is executed by the HIR evaluator.
6:17:48
no-defun-allowed
Here is that form, with a comment indicating where I put the quote: <https://plaster.tymoon.eu/view/2437>
6:18:58
no-defun-allowed
But it is totally a guess, based on how the ARGUMENTS- symbol is quoted in the case where (NOT (CONSP METHOD)).
6:20:44
beach
So if you quoted it and bootstrapping succeeds, then that means that the result of that code was never executed during bootstrapping. That's ... fascinating.
6:23:38
no-defun-allowed
I forgot to check after conversion, but MIR-to-LIR won't work if there are uninitialized lexical locations.
6:25:40
no-defun-allowed
Well, it now signals an error because I haven't written register allocation methods for SAVE-VALUES-INSTRUCTION.
6:27:11
no-defun-allowed
Still, it is odd that the compiler introduces a bogus lexical location, instead of reporting that the variable is unbound.