2016-09-09T00:08:28Z Cooler_ quit (Read error: Connection reset by peer)
2016-09-09T00:11:27Z slyrus quit (Ping timeout: 276 seconds)
2016-09-09T00:31:14Z attila_lendvai quit (Ping timeout: 260 seconds)
2016-09-09T00:35:29Z rumbler31 joined #sbcl
2016-09-09T00:40:26Z rumbler31 quit (Ping timeout: 250 seconds)
2016-09-09T01:24:38Z sjl quit (Ping timeout: 250 seconds)
2016-09-09T01:26:20Z sjl joined #sbcl
2016-09-09T01:31:12Z stassats quit (Ping timeout: 244 seconds)
2016-09-09T01:44:37Z em1l joined #sbcl
2016-09-09T01:48:14Z em1l_ quit (Ping timeout: 260 seconds)
2016-09-09T01:59:56Z nzambe joined #sbcl
2016-09-09T02:00:21Z rumbler31 joined #sbcl
2016-09-09T02:05:22Z rumbler31 quit (Ping timeout: 250 seconds)
2016-09-09T02:11:21Z sjl quit (Ping timeout: 244 seconds)
2016-09-09T03:57:44Z slyrus joined #sbcl
2016-09-09T04:28:30Z shka_ joined #sbcl
2016-09-09T04:47:13Z rumbler31 joined #sbcl
2016-09-09T04:51:20Z rumbler31 quit (Ping timeout: 250 seconds)
2016-09-09T05:54:10Z shka_ quit (Ping timeout: 252 seconds)
2016-09-09T06:31:34Z scymtym quit (Ping timeout: 240 seconds)
2016-09-09T06:45:05Z karswell quit (Remote host closed the connection)
2016-09-09T06:45:18Z karswell joined #sbcl
2016-09-09T06:56:36Z angavrilov joined #sbcl
2016-09-09T07:26:27Z gingerale joined #sbcl
2016-09-09T07:34:26Z scymtym joined #sbcl
2016-09-09T08:22:28Z Bike quit (Quit: draw your zeitgeber)
2016-09-09T09:11:15Z Xof: scymtym: could we not generate that list as part of the build process itself, and then use it to dump xrefs compactly in genesis (and subsequently)?
2016-09-09T09:12:03Z karswell quit (Remote host closed the connection)
2016-09-09T09:12:17Z karswell joined #sbcl
2016-09-09T09:39:55Z ASau quit (Ping timeout: 250 seconds)
2016-09-09T10:14:20Z scymtym: Xof: i'm not sure i understand the suggestion. collecting the data while building the cross compiler would require somehow hooking into the host compiler and give partial results anyway. on the other hand, iiuc, hooking into the cross-compiler to collect the data would be to late as it is already building the target core including xref info
2016-09-09T10:34:40Z DavidGu joined #sbcl
2016-09-09T11:00:20Z Xof: hooking into the cross compiler to build xref info
2016-09-09T11:00:57Z Xof: then inspecting that xref info to find out what the common symbols are, and when building the cold core store the common symbols information and also rewrite the xref info to compact form
2016-09-09T11:02:27Z flip214: Is there some contrib or so that creates a dwarf file out of the available debug information?
2016-09-09T11:08:39Z scymtym: ah, rewriting the xref info, i see
2016-09-09T11:09:56Z scymtym: then, why not start with an empty list of commonly xreffed symbols, build everything, and finally, somewhere near the end of the build process, compute the frequencies and re-pack
2016-09-09T11:11:04Z scymtym: could even keep the re-packer in the image
2016-09-09T11:11:38Z Xof: right
2016-09-09T11:12:08Z Xof: only if the repacker takes less than 1.5MB :-)
2016-09-09T11:17:04Z scymtym: of course :) we may also remove it to not have it perceived as a tuning nob for users
2016-09-09T11:17:29Z scymtym: i could discussions similar to the ones regarding tree shaking otherwise
2016-09-09T11:17:36Z scymtym: *could imagine
2016-09-09T12:10:44Z gargaml quit (Quit: WeeChat 1.5)
2016-09-09T12:18:05Z madbub joined #sbcl
2016-09-09T12:25:17Z stassats joined #sbcl
2016-09-09T12:28:30Z DavidGu quit (Ping timeout: 265 seconds)
2016-09-09T12:36:37Z sjl joined #sbcl
2016-09-09T12:49:16Z nyef`: G'morning all.
2016-09-09T12:50:34Z gargaml joined #sbcl
2016-09-09T12:50:59Z nyef`: stassats: Are lp#309127 and lp#1203260 further examples of lp#1523149 ?
2016-09-09T12:51:13Z stassats: lp 309127
2016-09-09T12:51:13Z specbot: https://bugs.launchpad.net/bugs/309127
2016-09-09T12:51:45Z stassats: lp 1203260
2016-09-09T12:51:46Z specbot: https://bugs.launchpad.net/bugs/1203260
2016-09-09T12:52:00Z stassats: 309127 is quite vague
2016-09-09T12:52:09Z stassats: "our compiler is dumb, do something!"
2016-09-09T12:53:25Z nyef`: Mmm. So it is, in retrospect.
2016-09-09T12:53:42Z nyef`: I was just looking through bugs tagged "compiler" that mention inlining.
2016-09-09T12:55:22Z stassats: 1203260 looks similar
2016-09-09T12:55:39Z stassats: but the fix is only confined to mv-combinations
2016-09-09T12:57:08Z nyef`: Okay, so there's at least one issue here, and possibly a small cluster, but it'll take actually understanding the inlining mechanism in order to fix it?
2016-09-09T12:57:30Z stassats: i think inlining itself is pretty clear
2016-09-09T12:57:48Z DGASAU quit (Ping timeout: 276 seconds)
2016-09-09T12:58:16Z stassats: perhaps the order is not clear, as in, why inlining stumbles upon deleted stuff
2016-09-09T12:58:29Z stassats: should it be done earlier?
2016-09-09T12:58:52Z stassats: it says, reimplement in terms of copying ir1, but if you copy it still can reference deleted stuff
2016-09-09T12:59:42Z stassats: only local inlined functions can reference the lexical environment, right?
2016-09-09T13:00:09Z stassats: lp 1523149
2016-09-09T13:00:10Z specbot: https://bugs.launchpad.net/bugs/1523149
2016-09-09T13:02:04Z DGASAU joined #sbcl
2016-09-09T13:03:04Z nyef`: I would think so, but if you pass an local inlined function as parameter to a non-local inline function, the lexcial references can migrate a bit, surely?
2016-09-09T13:03:06Z stassats: made another variation https://bugs.launchpad.net/sbcl/+bug/1523149/comments/5
2016-09-09T13:03:16Z stassats: smaller test case for one of the failure modes
2016-09-09T13:03:56Z stassats: nyef`: but it still involves local functions
2016-09-09T13:04:54Z stassats: ok, all those test cases involve XEPs, can i construct one without it?
2016-09-09T13:05:08Z stassats: i can
2016-09-09T13:05:16Z stassats: (lambda () (fun)) instead of #'fun
2016-09-09T13:05:34Z DGASAU quit (Write error: Connection reset by peer)
2016-09-09T13:06:31Z stassats: or http://paste.lisp.org/display/325613 for ir2-lvar thing
2016-09-09T13:06:39Z stassats: without calling PRINT or having XEPs
2016-09-09T13:07:08Z stassats: ok, i think we understand the causes very well and can trigger this at will
2016-09-09T13:07:14Z DGASAU joined #sbcl
2016-09-09T13:07:18Z nyef`: Well, YOU do. d-:
2016-09-09T13:07:34Z stassats: i'm a subset of WE
2016-09-09T13:07:59Z nyef`: Heh.
2016-09-09T13:10:43Z stassats: superficial causes, not the underlying ones
2016-09-09T13:15:20Z nyef`: The common theme here seems to be the NLX?
2016-09-09T13:16:30Z nyef`: But not for lp#1203260. Hrm.
2016-09-09T13:17:42Z nyef`: Ah, there's a closure.
2016-09-09T13:17:53Z nyef`: The common theme is the closure environment?
2016-09-09T13:19:08Z stassats: something closed over, yes
2016-09-09T13:19:19Z stassats: and then kinda unused
2016-09-09T13:19:30Z stassats: i'll try to make it without an exit
2016-09-09T13:19:54Z nyef`: lp#1203260 doesn't look like it has an exit.
2016-09-09T13:20:08Z nyef`: And I'm wondering if the &REST parts of the arglists are necessary.
2016-09-09T13:20:43Z stassats: well, i'm not sure what is causing it in 1203260
2016-09-09T13:23:03Z stassats: (defun f (x) (flet ((g (m) (declare (ignore m)) x)) (declare (inline g)) (g x) (apply #'g x))) works
2016-09-09T13:23:09Z stassats: (as in doesn't work)
2016-09-09T13:25:30Z stassats: http://paste.lisp.org/display/325613#1
2016-09-09T13:26:24Z stassats: i'm not convinced that it's actually the same thing now
2016-09-09T13:26:36Z stassats: but something adjacent
2016-09-09T13:26:50Z nyef`: Well, that's good news/bad news, isn't it?
2016-09-09T13:27:33Z stassats: i'll need something without mv-call and without return
2016-09-09T13:28:22Z stassats: but here it involves a closure of a variable, maybe that's what's being missing
2016-09-09T13:28:45Z stassats: well, it even fails in PHYSENV-ANALYZE
2016-09-09T13:58:25Z cromachina quit (Read error: Connection reset by peer)
2016-09-09T14:18:38Z rumbler31 joined #sbcl
2016-09-09T14:22:53Z rumbler31 quit (Ping timeout: 250 seconds)
2016-09-09T14:35:23Z attila_lendvai joined #sbcl
2016-09-09T14:35:23Z attila_lendvai quit (Changing host)
2016-09-09T14:35:23Z attila_lendvai joined #sbcl
2016-09-09T14:40:41Z edgar-rft quit (Quit: edgar-rft)
2016-09-09T15:13:59Z stassats: but if i inline by hand the exit ctran isn't deleted
2016-09-09T15:45:54Z attila_lendvai quit (Ping timeout: 260 seconds)
2016-09-09T16:03:24Z Bike joined #sbcl
2016-09-09T16:04:52Z stassats: huh, so MAYBE-EXPAND-LOCAL-INLINE converts a lambda does change-ref-leaf and that triggers re-optimization
2016-09-09T16:05:09Z stassats: which in turn triggers maybe-let-convert, but it converts the original call, not the expanded one
2016-09-09T16:05:38Z stassats: because there's now only one reference to the original function?
2016-09-09T16:05:41Z stassats: interesting
2016-09-09T16:06:45Z stassats: that's right, two calls to a local, one gets inlined the other immediately goes into let conversion
2016-09-09T16:07:17Z stassats: (tested with three calls, it's delayed by one inlining)
2016-09-09T16:24:03Z nyef`: What the... I have an LVAR with no USES?
2016-09-09T16:24:19Z nyef`: Also no DEST.
2016-09-09T16:24:25Z stassats: what are you investigating?
2016-09-09T16:24:33Z nyef`: (lambda (x) (let ((foo (lambda () x))) (declare (dynamic-extent foo)) (bar foo)))
2016-09-09T16:24:54Z nyef`: Slapped a BREAK in LVAR-GOOD-FOR-DX-P, and am taking a poke around.
2016-09-09T16:25:27Z stassats: i think we never could dx LAMBDAs
2016-09-09T16:25:35Z nyef`: Exactly!
2016-09-09T16:25:36Z stassats: which is strange
2016-09-09T16:26:00Z nyef`: We can DX a FLET or a LABELS, we can DX various other data-ish things, so why not a LAMBDA?
2016-09-09T16:26:39Z nyef`: Since it can transform to a FLET with a GENSYM name and an immediate reference anyway.
2016-09-09T16:27:37Z nyef`: So, the lambda above involves a single call to LVAR-GOOD-FOR-DX-P, and the LVAR isn't making any sense to me.
2016-09-09T16:27:50Z nyef`: And it IS in PHYSENV-ANALYZE.
2016-09-09T16:29:25Z madbub quit (Ping timeout: 250 seconds)
2016-09-09T16:32:12Z shka_ joined #sbcl
2016-09-09T16:34:25Z stassats: maybe-let-convert returns T even if it doesn't do anything
2016-09-09T16:34:54Z nyef`: Ah, this LVAR has been spliced out somehow, but is still referenced as something to do with the DX cleanup.
2016-09-09T16:40:21Z stassats: ok, so in reality the maybe-let-convert invoked as a result of MAYBE-EXPAND-LOCAL-INLINE actually does nothing
2016-09-09T16:40:58Z nyef`: ... Do we have something that automatically DXes parameters to certain functions?
2016-09-09T16:41:05Z nyef`: I'm vaguely remembering something about that.
2016-09-09T16:41:26Z stassats: well, not really automatically, but check out EVERY or SOME
2016-09-09T16:43:03Z jdz quit (Ping timeout: 264 seconds)
2016-09-09T16:43:06Z stassats: or anything that uses map
2016-09-09T16:43:17Z nyef`: Yeah, definitely not what I'm thinking of.
2016-09-09T16:43:19Z stassats: but i guess it gets actually inlined
2016-09-09T16:43:40Z stassats: ah, no, every does not get inlined
2016-09-09T16:43:55Z stassats: but it transforms the lambda into a flet
2016-09-09T16:44:02Z nyef`: Anyway, step one for me is to figure out what's going on with this LVAR.
2016-09-09T16:47:50Z stassats: even without any compilation failing some stuff that is going on is quite strange
2016-09-09T16:48:34Z jdz joined #sbcl
2016-09-09T16:48:42Z nyef`: Hrm. It's a LAMBDA-VAR and references at some point, but something snaps the links so that it refers to the CLAMBDA directly instead of to the LAMBDA-VAR, and then removes the LAMBDA-VAR itself as unused.
2016-09-09T16:49:10Z nyef`: So, the question becomes "what's different about a DX FLET here?"
2016-09-09T16:59:17Z gargaml quit (Quit: WeeChat 1.5)
2016-09-09T17:03:26Z nyef`: FLET/LABELS do %%allocate-closures insertion directly, and prep the DX environment as a new ENTRY if necessary.
2016-09-09T17:05:27Z stassats: interestingly, actually the surrounding lambda is causing the BLOCK to be deleted
2016-09-09T17:05:40Z stassats: ((lambda ())) stuff
2016-09-09T17:05:41Z stassats: weird
2016-09-09T17:06:24Z nyef`: FUNCTION uses WITH-FUN-NAME-LEAF, which also does %%allocate-closures insertion if it believes it to be necessary.
2016-09-09T17:06:26Z stassats: from move-return-stuff
2016-09-09T17:12:06Z rszeno joined #sbcl
2016-09-09T17:13:06Z stassats: ok, there is (REMOVE-FROM-DFO #<CBLOCK NIL :START c4 {1005FEC6F3}>)
2016-09-09T17:13:23Z stassats: but in a crashing case it doesn't get recognized as being deleted
2016-09-09T17:13:52Z stassats: which is checked with (not (block-component block))
2016-09-09T17:14:05Z stassats: remove-from-dfo does (setf (block-component block) nil)
2016-09-09T17:14:11Z stassats: yet somehow it grows it back
2016-09-09T17:16:11Z stassats: ok, it's actually a different block being removed
2016-09-09T17:21:00Z madbub joined #sbcl
2016-09-09T17:21:12Z stassats: ok, there's (REMOVE-FROM-DFO #<CBLOCK 5 :START c65 {100F5E33D3}>) and it fails on (IR2-CONVERT-BLOCK #<CBLOCK 5 :START c65 {100F5E33D3}>)
2016-09-09T17:22:07Z stassats: IR2-CONVERT walks blocks using do-ir2-blocks
2016-09-09T17:24:23Z attila_lendvai joined #sbcl
2016-09-09T17:34:56Z stassats: ok, right after (REMOVE-FROM-DFO #<CBLOCK 5 :START c26 {100A4C88A3}>) it does (ADD-TO-DFO #<CBLOCK 5 :START c26 {100A4C88A3}> #<CBLOCK 11 :START c4 {100A458973}>)
2016-09-09T17:38:58Z stassats: ok, nothing to latch on to here
2016-09-09T17:42:58Z stassats: but i think i might have something for the deleted ctrans
2016-09-09T17:43:48Z pipping left #sbcl
2016-09-09T17:59:30Z stassats: block pushes the next ctran into lexenv, but when it gets let converted the ctran is replaced with the a different one
2016-09-09T17:59:42Z stassats: so one something looks up up the lexenv it sees a ctran in a removed block
2016-09-09T17:59:54Z stassats: so, i somehow need to change the lexenv entry
2016-09-09T18:02:34Z scymtym quit (Ping timeout: 255 seconds)
2016-09-09T18:04:48Z stassats: the problem, i can't get to the lexenv
2016-09-09T18:04:55Z stassats: from let-convert
2016-09-09T18:05:16Z nyef`: Do you have the old ctran?
2016-09-09T18:05:22Z stassats: i guess
2016-09-09T18:05:42Z stassats: something like (node-lexenv (ctran-use ctran))?
2016-09-09T18:06:20Z nyef`: Or (node-lexenv (ctran-next ctran)), but it may be "too late" by that point for either to be reasonable.
2016-09-09T18:12:15Z stassats: well, (ctran-use ctran) is NIL
2016-09-09T18:12:22Z stassats: and (node-lexenv (ctran-next ctran)) doesn't have the right lexenv
2016-09-09T18:12:34Z nyef`: It's a former block-start ctran?
2016-09-09T18:12:56Z stassats: KIND   = :BLOCK-START
2016-09-09T18:13:06Z nyef`: Yeah, that's going to have a NIL CTRAN-USE.
2016-09-09T18:24:18Z scymtym joined #sbcl
2016-09-09T18:25:01Z stassats: (node-lexenv (block-last (block-prev (ctran-block (node-prev (lambda-return fun))))))
2016-09-09T18:25:39Z nyef`: Ouch.
2016-09-09T18:26:01Z nyef`: If you use that, definitely put a FIXME or KLUDGE comment on it. d-:
2016-09-09T18:26:07Z stassats: and i doubt it's right for all cases
2016-09-09T18:26:18Z nyef`: Or, you know, find out where the lexenv isn't getting updated the first time, and update it then?
2016-09-09T18:26:23Z nyef`: Or IS this that place?
2016-09-09T18:26:49Z stassats: it's the place where the blocks get merged together
2016-09-09T18:28:03Z stassats: i think i can do a bit better, though
2016-09-09T18:32:54Z stassats: well, i can get to the entry created by BLOCK
2016-09-09T18:36:26Z stassats: i can do (dolist (entry (lambda-entries fun)) (dolist (exit (entry-exits entry)) (describe (lexenv-blocks (node-lexenv exit)))))
2016-09-09T18:44:36Z stassats: while i was searching for the original ctran i forgot how to get to the new one
2016-09-09T18:44:37Z stassats: sigh
2016-09-09T18:45:13Z nyef`: Mmm. I'm at the point in my investigation where I need to start taking serious notes.
2016-09-09T19:05:50Z stassats: still can't find the new ctran
2016-09-09T19:05:58Z stassats: oh so close
2016-09-09T19:20:29Z DGASAU quit (Read error: Connection reset by peer)
2016-09-09T19:21:33Z DGASAU joined #sbcl
2016-09-09T19:29:22Z stassats: well, i think i caught it
2016-09-09T19:29:23Z stassats: but
2016-09-09T19:29:43Z stassats: now the function that reported note: implementation limitation: couldn't inline expand because expansion refers to the optimized away object #<CTRAN 1 {10065428C3}>.
2016-09-09T19:29:55Z stassats: fails with same The value NIL is not of type SB-C::IR2-LVAR
2016-09-09T19:30:10Z stassats: which is as if i added to it (declaim (optimize debug))
2016-09-09T19:33:23Z stassats: i'm not actually sure what i did is right as a result, it just fails in another place
2016-09-09T19:35:13Z stassats: but i increased my comprehension immensely
2016-09-09T19:36:15Z sjl quit (Ping timeout: 276 seconds)
2016-09-09T19:43:22Z myrkraverk: Should this work?  As in, not throw an error?
2016-09-09T19:43:30Z myrkraverk: (read-from-string "(foo" :eof-error-p nil)
2016-09-09T19:43:37Z myrkraverk: It throws me into the debugger in SBCL.
2016-09-09T19:49:41Z stassats: it's (read-from-string "(foo" nil), for starters
2016-09-09T19:50:03Z angavrilov quit (Remote host closed the connection)
2016-09-09T19:52:30Z stassats: and even then, it would signal an error
2016-09-09T19:53:54Z nyef`: Right, not from having hit EOF, but from having hit EOF in the middle of a form.
2016-09-09T20:00:49Z gingerale quit (Remote host closed the connection)
2016-09-09T20:15:32Z rszeno quit (Quit: Leaving.)
2016-09-09T20:15:56Z nyef`: My new trick for today: (sb-int:encapsulate 'sb-c::physenv-analyze nil (lambda (pa component) (sb-c::print-all-blocks component) (funcall pa component)))
2016-09-09T20:16:09Z nyef`: Prints the IR1 structure on entry to physenv analysis.
2016-09-09T20:19:35Z nyef`: ... Hey, wait. Isn't this a variation on the whole "advice" thing?
2016-09-09T21:04:08Z nyef`: Oh, I have an idea on how to auto-DX arguments for known functions if we don't already do it.
2016-09-09T21:19:16Z madbub quit (Ping timeout: 252 seconds)
2016-09-09T21:29:18Z ASau joined #sbcl
2016-09-09T21:29:21Z slyrus quit (Ping timeout: 244 seconds)
2016-09-09T21:37:01Z slyrus joined #sbcl
2016-09-09T21:51:24Z fe[nl]ix quit (Remote host closed the connection)
2016-09-09T21:51:24Z Blkt quit (Read error: Connection reset by peer)
2016-09-09T21:51:40Z fe[nl]ix joined #sbcl
2016-09-09T21:51:40Z Blkt joined #sbcl
2016-09-09T21:52:50Z fe[nl]ix quit (Remote host closed the connection)
2016-09-09T21:52:50Z Blkt quit (Read error: Connection reset by peer)
2016-09-09T21:53:04Z Blkt joined #sbcl
2016-09-09T21:53:05Z fe[nl]ix joined #sbcl
2016-09-09T21:54:03Z fe[nl]ix quit (Remote host closed the connection)
2016-09-09T21:54:04Z Blkt quit (Read error: Connection reset by peer)
2016-09-09T21:54:19Z Blkt joined #sbcl
2016-09-09T21:54:20Z fe[nl]ix joined #sbcl
2016-09-09T22:11:38Z edgar-rft joined #sbcl
2016-09-09T22:12:26Z karswell quit (Remote host closed the connection)
2016-09-09T22:12:30Z karswell` joined #sbcl
2016-09-09T22:16:10Z stassats: in (lambda (x) (declare (optimize debug))((lambda () (block nil (flet ((fff (x) (return x))) (declare (inline fff)) (if x (fff 1) (fff 2)))))))
2016-09-09T22:16:28Z stassats: for some reason (fff 2) goes through a cast
2016-09-09T22:16:44Z stassats: and that cast's lvar is missing lvar-info
2016-09-09T22:17:11Z stassats: (fff 1) goes where the cast from (fff 2) is going
2016-09-09T22:18:45Z stassats: (fff 2) is inlined, (fff 1) is let converted
2016-09-09T22:20:26Z nyef`: Wait, isn't this... lp#655042?
2016-09-09T22:20:36Z stassats: lp 655042
2016-09-09T22:20:36Z specbot: https://bugs.launchpad.net/bugs/655042
2016-09-09T22:20:46Z stassats: nyef`: not really
2016-09-09T22:20:58Z nyef`: Ah, okay.
2016-09-09T22:21:03Z stassats: well, it's close
2016-09-09T22:21:57Z stassats: i looked recently at 655042, basically it boils down to move-return-uses deriving types for all returns
2016-09-09T22:22:04Z stassats: but here there is no conflicts or anything
2016-09-09T22:22:46Z stassats: the ;; FIXME: Replace the call with unsafe CAST. -- APD, 2003-01-26 is basically right
2016-09-09T22:23:37Z stassats: so, (fff 2) is first expanded into (LOCAL-INLINE (FLET FFF)), and that is then let-converted
2016-09-09T22:23:47Z stassats: but with a cast (where does the cast come from?)
2016-09-09T22:28:04Z stassats: here's the trace http://paste.lisp.org/display/325613#2
2016-09-09T22:28:33Z stassats: 30: cast v28 -[#<NAMED-TYPE *> -> #<NAMED-TYPE *>]
2016-09-09T22:28:47Z stassats: and v30 is not used by the successor
2016-09-09T22:28:53Z stassats: 30: cast v28 -[#<NAMED-TYPE *> -> #<NAMED-TYPE *>]
2016-09-09T22:28:55Z stassats: err
2016-09-09T22:29:05Z stassats: return v25 CLAMBDA (LAMBDA (X)) and 25 is '1
2016-09-09T22:29:07Z shka_ quit (Ping timeout: 252 seconds)
2016-09-09T22:29:47Z stassats: that explains why it returns garbage when i hush this error
2016-09-09T22:30:30Z stassats: right, (funcall * t) 1, (funcal * nil) => #<FUNCTION (LAMBDA (X)) {100F7FA93B}>
2016-09-09T22:31:19Z stassats: something's messed really up
2016-09-09T22:31:36Z stassats: but i feel much more comfortable snooping around this
2016-09-09T22:37:10Z stassats: here's the trace without a surrounding ((lambda () )) http://paste.lisp.org/display/325613#3
2016-09-09T22:37:27Z stassats: there is still that strange cast, but it goes to the right place
2016-09-09T22:38:15Z nyef`: Wait, IR1 block 4?
2016-09-09T22:38:47Z nyef`: That looks like a vestigial exit cast.
2016-09-09T22:39:13Z stassats: and vestigial exits are infamous for?
2016-09-09T22:39:40Z nyef`: Stack analysis bugs.
2016-09-09T22:41:06Z fe[nl]ix: nyef`: https://github.com/sionescu/sbcl/commit/5bdf435ba7ed071dad1f3a8da3499782c25663a2
2016-09-09T22:41:19Z stassats: i think somehow the ctran it finds from RETURN-FROM is actually bogus
2016-09-09T22:41:43Z stassats: that's why when i "fixed" up move-return-uses i got the same error
2016-09-09T22:41:46Z fe[nl]ix: it's alive, mwahahaha
2016-09-09T22:41:53Z fe[nl]ix: or something like that
2016-09-09T22:42:36Z stassats: and that's why it goes seaside
2016-09-09T22:43:45Z stassats: so, let converting ((lambda ())) messes up with the block
2016-09-09T22:44:08Z nyef`: fe[nl]ix: Oh my.
2016-09-09T22:45:24Z fe[nl]ix: nyef`: I mentored the intern and the initial code was foom's
2016-09-09T22:45:26Z stassats: when there are multiple exits from ((lambda ()))
2016-09-09T22:45:44Z fe[nl]ix: but we get working executables
2016-09-09T22:47:19Z stassats: though, the successor is correct, the lvar it writes the value to is not
2016-09-09T22:47:51Z fe[nl]ix: I'm working to get it tested on QPX, and when we're satisfied that it can go live I'll split it into several patches and send 'em your way for review
2016-09-09T22:48:08Z nyef`: Nice.
2016-09-09T22:48:17Z stassats: my browser chockes on it, is including libelf neccessary?
2016-09-09T22:48:39Z nyef`: fe[nl]ix: Did you see the former-Microexplorer MacIIx on eBay recently?
2016-09-09T22:49:05Z nyef`: No software, unfortunately, otherwise I might have tried to get it.
2016-09-09T22:49:20Z fe[nl]ix: stassats: yes because the libelf variants present on Linux and on the BSDs are different
2016-09-09T22:49:21Z nyef`: Also none of the mX hardware.
2016-09-09T22:49:33Z fe[nl]ix: and RedHat's libelf is GPL2
2016-09-09T22:50:17Z fe[nl]ix: this one was taken from FreeBSD 10.2
2016-09-09T22:50:43Z stassats: block records the lvar, maybe i need not only substitute the ctran but lvar too
2016-09-09T22:51:05Z fe[nl]ix: unfortunately I have no solution for OSX
2016-09-09T22:51:17Z stassats gets unreasonably excited, probably about to be crushed by reality
2016-09-09T22:51:31Z sjl joined #sbcl
2016-09-09T22:51:42Z fe[nl]ix: best chance may be clang
2016-09-09T22:52:00Z fe[nl]ix: llvm actually
2016-09-09T22:52:00Z fe[nl]ix: but that's C++
2016-09-09T22:52:03Z stassats: fe[nl]ix: what is it actually doing?
2016-09-09T22:52:05Z stassats: elf fasls?
2016-09-09T22:52:43Z fe[nl]ix: no, it dumps the core as an ELF object
2016-09-09T22:52:54Z fe[nl]ix: ELF fasls are trickier
2016-09-09T22:53:17Z stassats: as opposed to appending to sbcl?
2016-09-09T22:53:24Z stassats: what's the benefit?
2016-09-09T22:53:25Z fe[nl]ix: then the static space, the read-only space and the dynamic space are mapped to ELF segments at fixed addresses
2016-09-09T22:54:07Z fe[nl]ix: that I can dump Lisp function addresses into .symtab
2016-09-09T22:54:22Z fe[nl]ix: and tey become visible to C++ debuggers and profiling tools
2016-09-09T22:55:02Z stassats: and when they move?
2016-09-09T22:55:29Z stassats: or is that why dougk_ was working on making then immovable?
2016-09-09T22:55:36Z nyef`: Pseudo-static doesn't move, does it?
2016-09-09T22:55:44Z fe[nl]ix: stassats: that's correct
2016-09-09T22:55:49Z fe[nl]ix: nyef`: and that's correct too
2016-09-09T22:56:03Z fe[nl]ix: so in practice I don't see them moving after core save
2016-09-09T22:57:05Z nyef`: Do we have any plans in place yet to have genesis output a page table and stuff code objects into a separate page pool from the common objects?
2016-09-09T22:57:51Z fe[nl]ix: Doug has some ideas
2016-09-09T22:58:13Z fe[nl]ix: and even half-done code, ISTR, for GC arenas
2016-09-09T22:58:51Z pkhuong: really stupid approach is to bake in a 100GB area when we build the runtime
2016-09-09T22:59:47Z fe[nl]ix: pkhuong: that's what I'm thinking as first step
2016-09-09T23:00:26Z pkhuong: and google flights can patch the linker script when they complain ;)
2016-09-09T23:01:48Z stassats: ok, patching up lexenv-block lvar truly fixes "implementation limitation: couldn't inline"
2016-09-09T23:02:09Z stassats: but not the original problem
2016-09-09T23:03:31Z stassats: but it's the same problem, i feel like i'm close
2016-09-09T23:04:36Z stassats: pretty exciting going from "i have no idea what the hell is going on and how to approach it" to "i feel like i'm close"
2016-09-09T23:07:32Z fe[nl]ix: pkhuong: http://paste.lisp.org/+6Z9N
2016-09-09T23:08:03Z fe[nl]ix: the save function also saves a file with the correct offsets, so no linker script used
2016-09-09T23:08:11Z fe[nl]ix: just command line options
2016-09-09T23:10:11Z stassats: and it's actually insert-debug-catch that affects it, as i suspected
2016-09-09T23:10:28Z fe[nl]ix goes to sleep
2016-09-09T23:10:45Z nyef`: fe[nl]ix: Sleep well.
2016-09-09T23:12:02Z fe[nl]ix: thanks
2016-09-09T23:15:06Z stassats: http://paste.lisp.org/display/325613#4
2016-09-09T23:15:09Z stassats: yay, no debug
2016-09-09T23:15:21Z stassats: so, it basically stops from being a tail call
2016-09-09T23:19:55Z stassats: i see, i tried replacing the lvar only when ctran matched, but the ctran is right here, the lvar is wrong
2016-09-09T23:24:42Z stassats: wham, fixed
2016-09-09T23:25:00Z stassats: testing all the test cases i conjured
2016-09-09T23:27:09Z nyef`: This sounds promising.
2016-09-09T23:28:52Z stassats: everything compiles fine
2016-09-09T23:29:05Z stassats: except a multiple value variant, but it's a different issue
2016-09-09T23:30:12Z stassats: so, in the end, it's actually pretty easy to explain: let conversion spliced in ir1 changing ctrans and lvars and the ctans and lvars saved in lexenv remained the same
2016-09-09T23:30:47Z stassats: i think (throw 'locall-already-let-converted exit-ctran) can go away now
2016-09-09T23:32:39Z stassats: will change it into an aver
2016-09-09T23:34:53Z nyef`: Congratulations.
2016-09-09T23:35:24Z stassats: i'll have to split https://bugs.launchpad.net/sbcl/+bug/1523149 though
2016-09-09T23:35:33Z stassats: since "A test cases which fails the same either way:" still fails
2016-09-09T23:48:14Z stassats: ok, that case is actually lp#1203260
2016-09-09T23:48:25Z stassats: i'll review pkhuong's fix and apply it
2016-09-09T23:48:41Z stassats: now that i'm more acquainted with let conversion
2016-09-09T23:53:48Z stassats: ok, all tests pass, even with a new AVER
2016-09-09T23:54:19Z stassats: i wonder if i can remove throw 'locall-already-let-converted everywhere, need to see how to induce that for functionals or lambda-vars
2016-09-09T23:55:17Z stassats: spoke too soon, ansi tests actually trips on that aver
2016-09-09T23:55:31Z stassats: or even on a different aver
2016-09-09T23:55:43Z stassats: AVER: (EQ (SB-C::CTRAN-KIND SB-C::CTRAN) :BLOCK-START)
2016-09-09T23:57:43Z stassats: (sigh)