freenode/#clasp - IRC Chatlog
Search
19:48:31
frgo_
Man, it took me a second look to get what I see. Real backtraces with real info in them. YES!
19:58:22
drmeister
With new stackmaps cclasp bitcode --> 25,113,174 lines of llvm-ir and 147 landingpads
20:03:06
drmeister
The good thing about all the complicated shadow stack and interweaving of the shadow stack with the real stack is that I can still use it all - and it merges interpreter frames with real frames.
21:52:39
drmeister
I haven't pushed to dev yet because I stashed the changes and I'm building with without the changes to see the impact on the number of lines of llvm-ir and landingpads
21:53:13
drmeister
Building cclasp [81 of 439] - as soon as it's done 10-15 min I'll pop the stash and push the changes.
21:54:48
drmeister
At [81 of 439] there are more than 8,000 landingpads - but we knew that it would be high.
23:22:09
drmeister
These new numbers are better than my previous estimates because they are from clasp with the new stackmap changes and then without the stackmap changes. It's as close a comparison as there can be.
3:02:46
drmeister
Wow! Fun fact - you can productively 'ediff' .ll files generated by different versions of clasp.
3:03:49
Colleen
Bike: drmeister said 21 hours, 24 minutes ago: After eliminating the shadow stack and the landingpads that were needed to support them I reduced the number of landing pads in cclasp from 55,562 to 147.
3:03:49
Colleen
Bike: drmeister said 20 hours, 53 minutes ago: Start keeping track of the total number of bitcode lines. I used (wc `find . -name '*.ll' -print`). Its a quick, rough measure of how much code we are generating.
3:06:05
drmeister
Yeah - there is no mystery - yesterday I was comparing to an old version of cando that appears to be very out of date and earlier today I was comparing to clasp before it had finished generating bitcode for 'inline.lisp'
3:15:20
drmeister
Also I have a question about the removal of temporary alloca's - they are replaced with llvm variables - do you give them names using gensym's? Or do you let llvm name them?
3:16:01
Bike
let llvm name them. i'd have to change things in translate-instruction to give them proper names.
3:17:05
drmeister
Because I am now thinking we should leave the naming to llvm - it might lead to better 'ediff'ability of the generated llvm-ir. That would help with improving code quality.
3:18:23
drmeister
Do you have any ideas of how to change literals to reduce the code size for inline.lsp?
3:27:41
drmeister
It's not too much to ask. We are essentially spitting out instructions for a little virtual machine.
3:37:37
drmeister
We should think this through with the new things we've learned over the last weeks.
3:50:58
drmeister
It's a bit fussy because I don't know the size of functions loaded from fasl files.