freenode/#clasp - IRC Chatlog
Search
2:13:25
drmeister
Bike: I was trying to get the shadow stuff to work using a declare. This should be enough - right? (defun foo (x y) (declare (debug 3)) ...)
2:15:03
drmeister
I thought I had it working earlier today but in the last hour I wasn't able to get shadow stack calls to be installed. Perhaps I did something wrong.
3:33:17
drmeister
The times I had shadow stack calls inserted into the function was in bclasp when I set the global variable that causes shadow stack calls to be inserted into every compiled function.
5:04:28
drmeister
::notify Bike I rebased your changes into mine and I'm rebuilding everything on this end. The new backtraces and fastgf changes appeared to work before the rebase and will hopefully continue to work.
5:05:25
drmeister
There's a longer delay now when Clasp starts up - about 7 seconds due to building about 250 dispatchers at startup.
5:06:04
drmeister
Also - the first compilation causes about 600 additional dispatchers to be compiled.
5:06:27
drmeister
It's the way that Clasp starts up - it evaluates every compiled top level form from start to finish.
5:07:11
drmeister
The good news is that this massive cascade of dispatcher compilations comes off without a hitch.
5:10:37
drmeister
We have some ideas of how we could generate the dispatchers at runtime and install them at startup - so that's not a deal breaker. Slow startup isn't a problem for scientific computation - but it is annoying for users.
12:09:30
Colleen
Bike: drmeister said 7 hours, 5 minutes ago: I rebased your changes into mine and I'm rebuilding everything on this end. The new backtraces and fastgf changes appeared to work before the rebase and will hopefully continue to work.
12:13:09
drmeister
Clasp built on my system - but I have a tiny patch to LLVM 5.0 installed that allows it to build on OS X.
12:13:55
drmeister
Clasp failed to build on linux (Shinmera's linut system) because his llvm 5.0 doesn't include that patch - and no one elses will either.
12:14:30
drmeister
The patch is just for disassemble, but it fixes a bug in llvm5.0 that at the moment, crashes the build. :-(
12:15:09
drmeister
So I need to put a #if /#endif around that code so that it builds ok with non-patched llvm5.0
12:15:11
frgo
Do we speak of stock LLVM 5.0 as installed by e.g. homebrew or do we talk about external-clasp's LLVM 5.0?
12:16:15
drmeister
I'm guessing both llvm 5.0 that you are describing were shipped with the bug. It's an easy fix on my end - I forgot to add it with all the other stuff I was doing.
12:19:00
drmeister
Check your llvm5.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h file - maybe it already has the patch - or you didn't get the latest version that I pushed about 7 hours ago.
12:19:48
drmeister
Check your hash as well. If you don't have the latest - you can wait until I wrap and #if/#endif around the effected code (a few hours).
12:24:18
drmeister
This patch allows clasp to generate meaningful backtrace information for JITted code at zero runtime cost.
12:25:39
drmeister
Great - the llvm web site says the release date for llvm 5.0.1 is "To be decided".
12:27:13
drmeister
In that case I'll add a conditional flag to wscript.conf that lets you use the patch if it's been applied and get better backtraces. Or disable the code that requires the patch and loose the names of JITted functions from the backtrace.
12:28:21
frgo
Don't bother what I am doing - It was menat as a pure comment. The less work for you the better
12:30:06
drmeister
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h#L103
12:31:42
drmeister
I couldn't figure out the error message the compiler was giving me before I knew about the fix. I thought they had done some weird C++ std::function vs lambda switch.
12:32:06
drmeister
I'm getting pretty good at reading C++ template programming compiler error messages - I lost it on this one.
12:39:37
frgo
Ok - but I figure the fix should be a "using" statement rather than doing the namespace annotation as pointed out by the diff, no?
12:40:47
drmeister
I haven't thought about it. Lang Hames - the guy who is developing ORC can deal with it.
13:02:11
Bike
it occured to me that SSA would also fix the redundant assignments problem, because once in SSA form any assignment is redundant (phi instructions not being assignments)
13:06:35
drmeister
Yes - llvm does remove a lot of redundant assignments - that's one reason I haven't been too worried about them.
13:07:22
Bike
having a bunch of temporaries around makes it harder to do a lot of analysis. it's why i couldn't do the un/box elimination
13:07:37
drmeister
But I know that we really have two compilers - and the second compiler (llvm) is picking up some of the slack.
13:09:15
Bike
and i think if we do SSA in HIR, we could skip mem2reg, and avoid redundant work that way. but mainly i want to be able to do analysis
13:12:04
beach
Tell me again the stereotypical case that causes problem in the type inferences; the one that would require value numbering to fix?
13:14:04
Bike
when the typeq is compiled, it makes a temporary, which x is stored in, so the typeq tests the temporary. then when you get to float-add, it uses x, not the temporary, so there's no type information from the typeq
13:16:09
beach
What is eliminated by SSA is assignments to variables that already have a value from previous assignments.
13:16:43
beach
The temporary is created once and not assigned to again. The variable x is not assigned to.
13:17:20
beach
HIR assignment instructions create variables. Including temporaries. Those assignments are still needed.
13:19:38
Bike
SSA itself won't, but without SSA i can't do it because it's possible the assignment is actually needed, because after the assignment X could be reassigned and then the temp used.
13:22:15
beach
SSA itself eliminates assignments to variables that have already been previously created and initialized.
13:25:08
Bike
if we did i could eliminate them pretty easily. so have an "actual assignment" instruction for setqs and a "create and initialize" otherwise?
13:26:32
beach
That is one possibility, yes. But notice that plenty of other instructions create and initialize temporaries.
13:27:52
beach
And I don't see how the task of eliminating "them" would be easier if we reserved the assignment instruction for the non-initial case.
13:29:49
beach
By the way, notice that we have been saying the entire time that SSA has this property, but so does SFA. We are still not using the fact that there is (statically) a single assignment to each variable.
13:30:44
beach
And I maintain that SSA ruins everything, because now you can't eliminate a predecessor to some instruction, even if you know that it can never be reached.
13:32:00
beach
That's what I mean. Before SSA, it doesn't matter how many predecessors an instruction has, and no order between them is defined.
13:32:33
beach
SFA just replaces a φ with an assignment (creation+initialization really) to the fresh variable in each of the predecessor arcs.
13:32:59
beach
... which has the same property as everyone wants, but not the particular problem that SSA has.