freenode/#clasp - IRC Chatlog
Search
11:53:26
drmeister
kpoeck: Thank you for the heads up on that fixup.lsp build problem yesterday. That would have been nasty today.
11:54:37
drmeister
Well, that's not quite fair - we got a docker build that built cleanly - so we could have used that.
11:55:49
kpoeck
I actually tried to do git reset to older commit, but obviously didn't go back long enough
11:56:19
drmeister
Sort of. I got the bullet proof backtrace to work just before we left. I was thinking about it as I drove. When I got to the hotel I checked a few things and noticed that the fastgf inline code was way bigger than I remembered it.
11:57:13
drmeister
Bike had moved it for logical reasons - I had forgotten how sensitive the fastgf stuff was to inline code size.
14:11:52
Colleen
Bike: drmeister said 8 hours, 59 minutes ago: - I pulled cc_dispatch_miss and cc_dispatch_debug out of fastgf.cc and put them into link_intrinsics.cc. It builds again. Doing this drops the boehm-fastgf-cxx.ll file down to 654 lines but with them it is 12153 lines. This shouldn't cause a crash (dunno what's up there) but it's way too large to inline into every discriminating function. I was very careful to check boehm-fastgf-cxx.ll so make sure ...
14:11:52
Colleen
Bike: drmeister said 8 hours, 58 minutes ago: - ... it stayed as small as possible and didn't drag in a lot of other code, which is apparently what happens when we add cc_dispatch_miss and/or cc_dispatch_debug. These are slow path and debugging functions - and one or both cause a LOT of other code to get dragged in to boehm-fastgf-cxx.bc.
14:14:23
drmeister
Right - once I moved those two out, the bitcode file dropped from 20,000+lines to ~600 lines.
14:15:01
drmeister
I still don't know why it crashed - it shouldn't have crashed even if the file is large.
14:15:34
drmeister
Try moving them back and then look at the .ll file that is generated (boehm-fastgf-cxx.ll)
14:15:41
Bike
do you have debug flags on? are they on by default? can we move cc_dispatch_miss but not _debug?
14:16:29
drmeister
If you move anything, look at the resulting .ll file before and after. That's the criterion. The file has to stay small and tight.
14:18:18
Bike
builtins.cc is stuff that is inlined, and intrinsics.cc that's inlined depending on wh ether it's compile or compile-file, right?
14:19:28
drmeister
intrinsics.cc is less controlled, link_intrinsics are things that should be linked to.
14:21:53
drmeister
Well, there is some history here. intrinsics are functions that are called directly via linking, not indirectly via funcall.
14:22:25
drmeister
fastgf.cc and builtins.cc get inlined into EVERY discriminating function and module generated by COMPILE respectively.
14:23:14
drmeister
intrinsics.cc are intrinsics that might be inlined if they are small enough and llvm decides its a good idea.
14:23:51
drmeister
For fastgf.cc and builtins.cc, llvm has no choice. We declare them always_inline.
14:25:51
Bike
builtins: "Small functions used by the runtime that should always be inlined." fastgf: "Small functions used by the fastgf runtime that should always be inlined."
14:26:17
Bike
intrinsics: "Small functions used by the runtime that may be inlined at the compiler's discretion." link_intrinsics: "Small functions used by the runtime that should NOT be inlined."
14:55:27
Bike
i guess the fastgf binary might have gotten bigger because i had to include some stuff and in C++ that goes weird sometimes
14:55:39
Bike
it just seems implausible that just cc_dispatch_debug could add tens of thousands of lines
17:30:27
Bike
so looking at the discriminating function vaslist business, we write the registers into a save area, then "rewind" the vaslist based on the save area
17:31:04
Bike
but i guess the register arguments probably do have to get into contiguous memory somehow