freenode/#clasp - IRC Chatlog
Search
14:40:45
hiro98-
i'm in the process. I am asking to find out if it is an arch problem before I start figuring stuff out.
14:41:05
Bike
we've had a few problems with arch. if you search for "arch" in the logs it should come up.
14:44:24
drmeister
We haven't got an Arch build in our buildbot - but we are expanding our buildbot over the next couple of weeks - I'll bring up the idea of an Arch build.
14:50:52
Bike
drmeister: got the satiation thing working. takes like two seconds to start up and then three to compile (lambda (x y) (+ x y))
14:52:36
Bike
this is also without any kind of stamp caching, so things work at least okay without it
14:54:07
drmeister
Using the 'dev' branch I can go: python3 waf build_cboehm -- so you can use python2 the same way.
14:57:30
Bike
here's a satiated discriminating function i happened to have up https://pastebin.com/wraXUsBR
14:57:48
hiro98-
Shinmera: https://gitlab.com/ita1024/waf/blob/master/waf-light some kind of self extracting archive? (file command says "waf: a /usr/bin/env python script executable (binary data)")
14:57:56
Bike
in the runtime version, the first let is nonexistent, and the outcomes look different.
14:58:47
drmeister
hiro98-: I didn't write it that way - waf is the build system that I hate the least.
15:00:02
Bike
i'm not sure whether bclasp does block and tagbody and empty lets efficiently. i hope so
15:39:28
drmeister
It's got the same look and feel as the crash last week - it's hung up in llvm InstCombiner.
15:41:16
drmeister
Bike: The only function you have moved into fastgf.cc right now is cc_dispatch_miss - correct?
15:44:35
drmeister
No - I don't think bloating is the problem. Only bad code generation would cause a crash like this.
15:45:36
drmeister
I don't understand why having cc_dispatch_miss 'always_inline' in fastgf.cc would lead to bad code generation - but it's looking like that's what is happening.
15:46:19
drmeister
I'm moving cc_dispatch_miss back into link_intrinsics.cc and rebuilding to test my hypothesis.
15:46:20
Bike
why don't you try reverting the commit to see if that fixes it. it's https://github.com/clasp-developers/clasp/commit/061466da2c1746910bcfb775e7813fa6ed858640
15:48:43
drmeister
Is cc_disptach_miss on a code path that returns normally - or does it unwind the stack?
15:50:39
Bike
but then, i'f been getting "bad instruction: 4" when i hit infinite recursion, so maybe everything else is worrying too
15:52:36
drmeister
Well, let's not panic. Everything else appears to be working. I need to get a copy of the module just before it goes to llvm for optimization. Then I might get some clue as to what is going on.
15:58:01
drmeister
Yep - I move that one function out of fixup.cc to link_intrinsics.cc and it builds fine.
15:59:02
drmeister
So add that to the criterion for what goes into fastgf.cc - "Only add functions that don't cause spooky crashes in llvm".
16:00:24
drmeister
Pushing the 'fix' for now - until we figure out what is going on. I don't really care about cc_dispatch_miss - it's on the slow path and there is no downside to putting it in link_intrinsics.cc. But what other functions we might add in the future would cause spooky crashes?!?!?
16:05:03
drmeister
Ok. I'm working to add code for DEBUG_FASTGF that will dump the modules after inlining fastgf bitcode
17:17:41
drmeister
None - I just pushed a "fix" that moves that function back to link_intrinsics.cc. I have made some changes to the code to dump the discriminating function llvm Module JUST before it gets compiled to see what it looks like when the function is in fastgf.cc vs link_intrinsics.cc
17:18:29
kpoeck
I asume I can build again with your fix, will know like in 2 hours when I am back home
17:18:54
drmeister
Don't worry - I have a really good idea of where and when it's happening. They why is still a mystery that I hope to get to the bottom of in the next hour.
17:19:54
drmeister
What's disturbing about this is that from my perspective, what Bike did moving that function into fastgf.cc was perfectly fine. But llvm doesn't think so.
17:23:29
drmeister
If we baked the symbol information into the FunctionDescriptions - then disassemble would have what it needs to work beautifully.
17:29:16
drmeister
stackmaps are already mmap'd into memory on Linux and macOS - so we don't need to worry about those. We just need their offsets on linux.
17:31:37
drmeister
Ok - I have clasp dumping discriminating function modules just before they get compiled. I did it first with cc_dispatch_miss in link_intrinsics.cc
17:37:27
drmeister
fastgf.cc contains cc_dispatch_miss - but it's not declared always_inline - so it's not inlined. Everything works!
17:39:28
drmeister
The discriminating function I pasted was the largest one that is generated while building bclasp.
17:53:11
drmeister
No - it's not unexpected. But we should look at the llvm-ir and see if it's worth moving into fastgf.cc
17:56:43
drmeister
I wish there were a way to install a debug version of llvm with brew - I can't find anything.