freenode/#clasp - IRC Chatlog
Search
14:21:18
Bike
the SSA paper cleavir cites mentions the transformationc an be used to eliminate redundancies. cool, then
14:24:25
Bike
it cites some other stuff on SSA, so i didn't think that was the case. maybe "the original SSA paper that made compiler writers pay attention" judging by the efficiencies
14:29:40
Bike
i'm looking at the SSA stuff in cleavir. i don't know if it works, but i assumed it would be relevant to SFA (the SFA file seems to be blank)
14:32:10
beach
The SSA code is in there, not because I think it is a good idea, but because there might be some Cleavir client that wants it.
14:36:51
beach
OK, I now have a test for LOCALLY [this is CST-to-AST]: (locally (declare (special x)) x) seems to work.
14:37:51
beach
Even when this stuff works, there are a lot of syntax checks missing, resulting in mysterious errors when incorrect code is submitted for conversion.
15:07:06
beach
OK, enough work for today. Time to do something else; something that requires less concentration.
15:15:44
beach
This is very typical for compiler technology. All work is done as if the only valid language is C.
15:17:45
beach
For example, when the nested function that shares a variable in only called, and not captured in any other way, control flow is predictable, so things should be easier then.
15:18:40
beach
Notice though that, as I hinted, I am to tired to do real work at this point, so also too tired to figure out exactly what cases would work.
15:19:24
Bike
SSA. Kildall. Lots of stuff. If you're too tired to think about it that's fine though.
15:20:12
beach
Yes, we have had this discussion before. I will figure it out eventually, but it is hard for me to jump between different tasks too frequently, so I am putting it off.
15:20:37
beach
It all depends on this famous extended control-flow calculation that I have mentioned several times I think.
15:21:17
Bike
You have, yes. But it's proven to be kind of a bottleneck for me so I'd like to help if I can.
15:22:28
beach
OK, let me put it on the back burner then and see whether I can come up with something that can make it easier for you to help.
15:56:31
beach
Let us say that it is extremely rare to have an assignment (other than the defining assignment) to a variable that contains a function, as in (let ((f (lambda ...))) ... (setf f ...))
15:57:38
beach
Then we can get a conservative idea of what happens to the value created by (lambda ....).
15:58:33
beach
It is conservative, in that, if the variable is assigned to, then we might incorrectly assume that the function is propagated in ways that it really isn't.
15:59:29
beach
Here, we may incorrectly conclude that it is possible for the function to become an argument to the call to G.
16:00:27
beach
We get a conservative idea of what happens to the function by looking at instructions that take F as an input.
16:00:59
beach
If the instruction is an assignment, we recursively consider the output of that instruction.
16:02:49
beach
It can be a function that we know will not hold on to the value, such as CONSP, FUNCTIONP, etc. For such cases, we can stop tracking.
16:04:37
beach
This analysis should cover the vast majority of cases, i.e., in most cases, we may have a nested function that we know is only going to be called.
16:08:09
beach
Anyway, just a thought as to how to break the interdependence between several phases.
16:09:42
beach
Because, to be more precise about what can happen to a function, we need value numbering, and value numbering requires knowledge about control flow, so we must break this cycle of dependence somehow.
16:12:34
beach
And of course, whether there really *is* capture is of course undecidable, so we need approximations anyway.
16:23:53
beach
Yes, we can't do a good control-flow analysis when we don't know which functions may be captured.
16:24:04
Bike
anyway, i already wrote a quick version of that when i was trying to do escape analysis, so that's heartening
16:24:07
beach
And we don't know what functions may be captured until we have a control-flow analysis.
16:26:04
beach
I'll continue thinking about it. Just wanted to think out loud. Especially given my state of fatigue.
16:32:28
beach
In general, I think we should think in terms of phases to successively increase our knowledge about the control flow. Then, we can start with simple implementations of each phase, and later, we might think of more precise analyses that we can do.
16:39:49
beach
For example, I can think of cases where this simple analysis gives a false positive in that it can not determine for sure that some function F is only called. But, once the result of this analysis is available and it has been determined that some other function, say G, is only called, this information will allow us to conclude that F is also only called.
16:40:11
beach
Not that I can come up with an example in real-time right now. I would have to play with it on paper.
16:57:47
Bike
a function that's only called could still be captured, right? or is this just to rule out functions being called at any time due to threading etc.
17:13:51
scymtym
i think "compiling with continuations" has something about iterative escape analysis. will have a look when home. that book can be a bit vague in places, though
17:43:11
shiho
drmeister I think I need index data to get atom name etc from energyAtomTable. How can I get all atom's index?
18:32:42
shiho
drmeister Sorry, I misstyped your name... You don't need to care about my 1:43pm question.
19:15:37
drmeister
I'm pretty sure the problem with slime is a race condition when fastgf is used with multiple threads
19:58:06
frgo
drmeister: Have you upgraded to Xcodse 9 already? (I am asking because I see strange compile errors)
20:00:56
drmeister
I did get a weird license approval request this morning and by slamming my hands on the keyboard for a few min while yelling loudly I got it to go away.
20:06:13
drmeister
Because here's the poop ... I mentioned some of this this morning - but I'll summarize.
20:07:27
drmeister
To get zero-cost backtraces I implemented code that gets the llvm JIT engine to tell us where JITted code is put in memory. It worked for about 15 min and then I upgraded to llvm 5.0 and it broke because of a bug in llvm 5.0 :-(
20:08:45
drmeister
Because I haven't tested that. I applied the patch and built llvm in a way that would not undo the patch.
20:09:12
drmeister
Perhaps you didn't build externals clasp again - or you used 'make' which might wipe out the patch.
20:09:39
drmeister
I don't know - I haven't gamed out the whole patch/no-patch/undone patch thing. The whole situation is annoying as F.
20:15:22
drmeister
If you pull the latest externals-clasp and use 'make really-clean' that will wipe out llvm 5.0 on your system, pull it down again, apply the patch and rebuild.
20:16:55
drmeister
Or... I just pushed a change to clasp 'dev' that ignores the broken code - but it doesn't give you backtrace info for JITted code - which isn't a huge deal unless you are developing code in Clasp.
20:17:21
drmeister
It ignores the broken code conditionally - you can tell Clasp that the patch is installed and then it will use it.
20:19:04
drmeister
If it's False then it won't use the broken llvm code. If it is True then it will assume the patch is installed and try to use it.
20:19:23
drmeister
If the patch isn't installed when you set LLVM5_ORC_NOTIFIER_PATCH = True then you will get the error that you just saw.