00:17:43 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 00:29:27 -!- echo-area [~user@114.254.99.176] has quit [Remote host closed the connection] 00:42:04 -!- heddwch is now known as hedd_recomposing 00:55:20 -!- jasom [~aidenn@ip70-191-80-19.sb.sd.cox.net] has left #sbcl 01:29:53 echo-area [~user@182.92.247.2] has joined #sbcl 01:32:10 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 01:33:13 -!- hedd_recomposing is now known as heddwch 02:00:35 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 02:12:52 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 02:15:38 ASau` [~user@p54AFF3C7.dip0.t-ipconnect.de] has joined #sbcl 02:16:43 -!- ASau [~user@p5083D591.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 02:34:01 32 revisions left. 03:06:45 -!- oleo [~oleo@xdsl-78-35-143-152.netcologne.de] has quit [Ping timeout: 248 seconds] 03:07:36 oleo [~oleo@xdsl-78-35-143-154.netcologne.de] has joined #sbcl 03:26:17 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 03:40:01 -!- christoph_debian [~christoph@ppp-88-217-51-196.dynamic.mnet-online.de] has quit [Ping timeout: 272 seconds] 03:41:34 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:45:25 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 03:52:53 christoph_debian [~christoph@ppp-46-244-233-28.dynamic.mnet-online.de] has joined #sbcl 04:23:14 -!- LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has quit [Quit: Leaving.] 04:37:20 -!- brucem [~bmitchene@waywardmonkeys.com] has quit [Read error: Connection reset by peer] 04:38:16 brucem [~bmitchene@waywardmonkeys.com] has joined #sbcl 04:45:42 -!- brucem [~bmitchene@waywardmonkeys.com] has quit [Quit: ZNC - http://znc.sourceforge.net] 04:47:06 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 04:48:30 brucem [~bmitchene@waywardmonkeys.com] has joined #sbcl 04:49:58 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 265 seconds] 05:01:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:16:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 272 seconds] 05:51:46 -!- oleo [~oleo@xdsl-78-35-143-154.netcologne.de] has quit [Remote host closed the connection] 06:05:51 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 06:13:52 sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 06:53:49 I've got one regression pinned to a commit that moves definitions around. 06:54:10 Literally the same functions and definitions, but in a different order in the same file. 06:55:27 Instead, I identified 5 potential discrepancies with the initial code. I'm testing all 32 combinations and we'll see if cl-bench can point at a good option. 06:56:07 -!- sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 246 seconds] 06:56:50 So far, it looks like, compared to the old allocator, various versions of the new one win a lot (15-20%) on a few macro benchmarks, and win/lose by ~5% on some micro benchmarks. 07:09:33 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 07:10:15 -!- ASau` is now known as ASau 07:11:29 prxq [~mommer@x2f6d42e.dyn.telefonica.de] has joined #sbcl 07:12:24 echo-area [~user@182.92.247.2] has joined #sbcl 07:36:30 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:54:13 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 08:05:07 this is a reduced test-case from a regression in cl-mustache: (let ((foo (vector 1.1))) (typecase foo ((vector hash-table) (assert nil)))) 08:05:21 i'm not sure, what should happen here 08:05:47 in current SBCL, clisp and ccl, the assertion fails 08:06:06 but SBCL seems to have behaved differently before 08:07:00 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 08:08:23 scymtym_: in 1.0.57 it fails ... 08:09:25 (typep #(1.1) '(vector hash-table)) => T in CMUCL, so, i don't think SBCL behaved any differently 08:09:52 hm, yeah, it may be more complicated 08:11:21 the actual output is at http://cl-test-grid.appspot.com/blob?key=89jk4dab8v 08:11:49 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 08:11:58 maybe the difference is that SBCL now derives that the array-elements should be of type hash-table 08:12:29 it always did so 08:14:39 ok, this seems to be what happens: (defun f (foo) (typecase foo (hash-table) (null) ((vector hash-table) (loop for a across foo do (print a))))) (f (vector 1.1)) => TYPE-ERROR 08:15:10 ams: could you test that in 1.0.57? 08:15:54 scymtym_: sure... 08:16:20 that didn't happen in 1.1.12 08:16:30 * (f (vector 1.1)) ;--> 1.1 08:16:30 .30 08:16:51 ams: thanks 08:18:12 and maybe it's a good idea that it now does do so 08:18:44 since (vector hash-table) type is just (vector t), and this is bound to cause problems 08:18:44 stassats: yeah, looks like an improvement to me 08:19:13 i guess it's caused by pkhuong's smarter type derivations for if/typep constructs 08:19:31 yes, it's clearly due to them 08:20:10 that merit a bug report against cl-mustache then, right? 08:20:35 in any case 08:20:55 stassats, ams: thanks for helping me understand this 08:21:02 expecting (vector hash-table) to typecheck for hashtables is never going to happen 08:24:40 scymtym_: and your error rank thing, it should be a unreachable code deletion error 08:25:18 stassats: i guess so 08:27:08 but the transform for array-rank doesn't receive the type 08:27:19 cl-mustache is already fixed but the fix is not yet in quicklisp 08:27:36 otherwise it would have been folded to 2 08:28:42 isn't that the problem, then? without folding the array-rank, the body of the when does not become dead code 08:28:43 scymtym_: i had a hack to create a local mirror for ql, and create packages for the versions from whatever you wanted (you could specify the hash tag/branch in a git repo) ... shouldn't be to hard to write again 08:30:29 ams: i test for SBCL regressions with a fixed quicklisp release, so precise control over project versions is not required; but thanks for the hint 08:30:49 scymtym_: ah, thought you wanted to just get the latest ... 08:31:22 annoyingly I think that the (vector hashtable) thing was conforming code 08:31:25 ams: quite the opposite: the point is having a fixed quicklisp and changing SBCL versions and see what changes 08:31:38 scymtym_: nod nod, makes perfect sense for this usage case 08:31:39 when used for discrimination (vector hashtable) just means (vector t) 08:31:49 it's when it's used for declaration that it means something different 08:32:03 the new typep constraint thingy probably needs to know about that 08:33:16 (defun f (foo) (declare ((x) foo)) (array-rank foo)) => The value # is not of type SB-KERNEL:ARRAY-TYPE. 08:33:38 interestingly, at least one implementation seems to use the vector element-type for discrimination: https://github.com/kanru/cl-mustache/commit/a8d17c03993068dcb68deddf30594badb6dc7f8e (or they just committed something that does nothing) 08:34:08 the transform doesn't check that the type is an array type indeed 08:35:30 scymtym_: I removed that line. it does nothing :/ 08:36:07 scymtym_: but newer sbcl seems to check that and fail at runtime 08:37:46 array-type-dimensions-or-give-up works with intersections, while the rest of transforms doesn't 08:37:58 s/of transforms/of the transform/ 08:41:15 interestingly, works only with (declare ((x) foo)), but not (declare (x foo)) 08:41:57 oh, it treats x is an unknown declaration, but (x) as a type 08:42:26 kanru: yes, that is what i "discovered" in regression tests with an older quicklisp release 08:42:38 so, (lambda (a) (array-rank (the x a))) is enough 08:50:19 in (typecase a ((array t 2) (array-rank a))), array-rank doesn't peak up the type 08:51:52 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 08:55:08 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 245 seconds] 08:55:58 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds] 08:58:55 it settles on the type too early, if i say to give up the transform instead of returning `(if (array-header-p array) (%array-rank array) 1), its optimized away on the second try 08:59:11 but that makes it worse when the type is truly not known 09:09:25 adding (delay-ir1-transform node :constraint) helped 09:11:25 (when (= (array-rank a) 3) (aref a 2)) could also have type mismatch error 09:14:24 i wonder how many transforms could benefit from such delays 09:52:40 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 09:57:29 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 10:04:53 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 248 seconds] 10:07:12 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 10:17:03 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 10:28:53 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 248 seconds] 10:32:40 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:53:32 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 10:58:39 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 11:28:57 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 11:47:28 abarch [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 11:53:24 -!- milosn [~milosn@user-5af5020b.broadband.tesco.net] has quit [Ping timeout: 246 seconds] 11:54:15 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 11:54:52 eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has joined #sbcl 11:55:04 milosn [~milosn@user-5af50e24.broadband.tesco.net] has joined #sbcl 11:58:49 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Read error: Operation timed out] 12:17:28 yacks [~py@103.6.159.103] has joined #sbcl 12:27:18 echo-area [~user@111.196.5.186] has joined #sbcl 12:43:45 segv- [~mb@95-91-240-222-dynip.superkabel.de] has joined #sbcl 12:55:13 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:55:56 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:56:12 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 13:11:20 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:25:31 leuler [~user@p548FA70C.dip0.t-ipconnect.de] has joined #sbcl 13:26:29 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 13:41:14 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:47:45 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 272 seconds] 13:52:42 milanj [~milanj@82.117.199.26] has joined #sbcl 13:54:45 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 14:05:29 -!- milanj [~milanj@82.117.199.26] has quit [Ping timeout: 272 seconds] 14:06:12 milanj [~milanj@82.117.199.26] has joined #sbcl 14:28:50 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:30:42 oleo [~oleo@xdsl-78-35-143-154.netcologne.de] has joined #sbcl 14:38:33 -!- lacedaemon [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 14:38:33 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [Remote host closed the connection] 14:38:43 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl 14:38:45 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 14:39:51 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 14:39:51 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [Remote host closed the connection] 14:40:04 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl 14:40:06 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 14:40:54 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 14:40:54 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [Remote host closed the connection] 14:41:02 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl 14:41:04 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 14:46:33 fisxoj [~fisxoj@dyn-129-97-41-253.dynamic.uwaterloo.ca] has joined #sbcl 15:10:20 JackEgivand [~jonathon@jnb-28.mse.ncsu.edu] has joined #sbcl 15:10:48 hey guys, im having a .... very strange error with sbcl 1.1.12 failing to run code that i wrote in 1.1.2 15:10:59 it doesnt seem to be in the bug tracker... 15:12:37 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 272 seconds] 15:12:40 specifically, i get an end of file error for (sb-impl::string-input-stream) when i.....do some rather complex unnesting 15:12:54 but the error doesnt occur at all on 1.1.2, which i wrote the code on 15:13:11 does...does anybody think they can help? 15:16:12 JackEgivand: paste the full backtrace somewhere 15:17:30 -!- oleo [~oleo@xdsl-78-35-143-154.netcologne.de] has quit [Ping timeout: 245 seconds] 15:18:44 oleo [~oleo@xdsl-87-79-199-186.netcologne.de] has joined #sbcl 15:20:27 http://pastebin.com/SS51t3Kp 15:20:35 theres the fully expanded backtrace 15:26:23 what's that PARSER function ? 15:26:30 hold on ill pastebin 15:27:24 http://pastebin.com/YaMQhKaN 15:27:42 -!- eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 15:27:53 the parser function is where everything hits the fan, based on my attempts to...narrow down where the error was occuring 15:28:31 value-strip uses split-sequence to break apart string-formatted vectors into lists and everything else in it is plain old sbcl 15:31:15 oh, and importer is just being used to call s-xml:read-xml-file with output type set to sxml 15:32:43 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 15:36:22 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 15:38:27 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 15:51:39 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 15:57:39 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 16:00:03 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:01:33 <|3b|> JackEgivand: what does VALUE-STRIP look like? 16:02:12 http://pastebin.com/VEC5KSwz 16:03:10 <|3b|> looks like you have extra non-space whitespace (newline specifically) in your input that you don't handle correctly 16:04:00 hmmm. that could be it ....let me see what happens if i change it to remove newlines as well 16:04:54 <|3b|> also, using ELT on every element of a list in order is a bit silly, maybe you wanted (loop for i in a (read-from-string i)) or (mapcar 'read-from-string a) 16:05:24 <|3b|> and parse-number instead of read-from-string if you didn't create the input data yourself, since READ can have arbitrary side effects 16:06:00 there is a reason that elt is being used. you see, theres a lot extraneous...well...crap that i want to remove from the sxml tree 16:06:18 <|3b|> in value-strip? 16:06:27 oh 16:06:28 that one 16:06:58 <|3b|> and even in parser, you don't have to use the value every iteration 16:07:30 <|3b|> and put COLLECT or COLLECTING at the beginning of a line, not end of previous line... easier to read/edit that way 16:09:04 hmmm 16:10:25 those points have a lot of merit...im still working on seeing if properly removing the newline characters fixes it, then i can get to thinking about those other points 16:13:25 eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has joined #sbcl 16:17:01 parse-num wont work, value strip also gets called on boolean and actual strings 16:18:10 hmm. im going to try splitting the sequence at linefeeds then concatenating the results 16:18:34 that way i have to change the minimum amount of code, and i'll see if that fixes it, as you suspect |3b| 16:21:09 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Quit: Leaving...] 16:21:55 well...that did fix that error...and generated another lol. but I think i can handle these. thanks for your help 16:26:47 -!- JackEgivand [~jonathon@jnb-28.mse.ncsu.edu] has left #sbcl 16:56:01 stassats: nearly everything would benefit from delaying after a pass of constraint. 16:59:12 Krystof: re new typep, how much code would it be to upgrade a type for typep ahead of time? 17:00:39 cmack [~charlie@adsl-74-179-28-220.bna.bellsouth.net] has joined #sbcl 17:04:04 stassats: not sure the delay is in the right place for array-rank: there's no transform on %array-rank. 17:04:25 it's a vop 17:04:49 And there's no type directed constant folding transform for it. 17:05:05 -!- segv- [~mb@95-91-240-222-dynip.superkabel.de] has quit [Ping timeout: 272 seconds] 17:05:20 i figured if it knows that the array is complex, it has all the information it can get 17:05:29 which may be not true in some cases, yes 17:10:28 pkhuong: hm, some code in compiler typep to handle array/not/or/and types, I guess 17:11:16 probably not too much 17:12:44 segv- [~mb@95-91-240-222-dynip.superkabel.de] has joined #sbcl 17:17:32 a transform on %array-rank seems simpler to me. 17:17:45 %array-rank is only for complex arrays 17:20:06 ok? 17:21:22 what would i transform simple arrays into? 17:23:26 it's internal code. It should just neer be called on non simple arrays, so you just suppose that won't happen and return whatever is easiest. 17:23:35 (sb-c::%array-rank nil) => -7, after all. 17:24:04 i've lost you there 17:24:59 so, backtracking, how should the array-rank transform look like? 17:25:06 -!- eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 17:25:51 just like it looked before. 17:27:10 now, how to fold when the type is known? 17:27:45 with a transform on %array-rank. 17:28:06 ok, that would work on complex arrays 17:28:54 if you mean that (array-header-p array) will be folded, and IF will resolve into 1, then i see it 17:30:01 Here's what I have here http://paste.lisp.org/display/140003 17:31:38 The delay in array-dimention isn't necessary for the test cases, but it seems like a good idea, regardless. 17:32:36 and the derive-type optimizer on array-header-p... I don't understand why it was written that way. 17:32:56 well, if you're going to handle it, then ok 17:34:18 but then, the array-rank transform can be simpler, can't it? just `(if (array-header-p array) (%array-rank array) 1) 17:34:56 no reason to slow down the compiler. 17:35:22 what about OAOO? 17:35:38 and this can be a source transform 17:37:15 if you're confident enough, then yes, a source transform. 17:38:19 but it's still more rounds of rewrites for a common case (the type is known well enough via a declaration). 17:38:49 why does typecase make it harder? 17:39:00 oh, i se 17:39:07 e 17:39:43 for a common case, it will only have to be put through array-header-p 17:39:57 and array-rank is really not something which will cause performance issues 17:40:45 of the compiler, that is 17:42:47 even if it's on a simple-array of rank 1, a-h-p will have to either go through an optimisation pass (and as a transform, some let conversion... but that should probably be fixed in ir1-optimize-combination), and then trigger a reoptimisation for the IF node. 17:44:13 in this case simplicity should win 17:47:18 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 17:54:17 that would likely be an inline declaration in code/array then 17:55:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 18:00:57 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 18:00:57 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 18:00:57 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:06:05 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 18:11:41 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:16:20 I see why we have regressions in regalloc for some of the array benches. We assign a really low cost to TNs that are live across many calls. It so happens that that is the case of most of the TNs in these benchmarks: the setup code is really call heavy. TN costs don't take loop depth into account, so we lose a lot on the nested loops that follow. 18:18:25 pkhuong: i don't really trust inline declarations 18:20:20 attila_lendvai [~attila_le@84-236-114-222.pool.digikabel.hu] has joined #sbcl 18:20:20 -!- attila_lendvai [~attila_le@84-236-114-222.pool.digikabel.hu] has quit [Changing host] 18:20:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:20:23 -!- echo-area [~user@111.196.5.186] has quit [Ping timeout: 246 seconds] 18:29:31 pkhuong: The regalloc performance numbers you wrote about earlier today sound really nice! 18:30:21 leuler: that's almost all the smarter spilling decisions. 18:31:15 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 18:43:41 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 18:44:58 pkhuong: So it seems even the initial commit of the new regalloc might be a large win. I didn't expect that after the things we saw yesterday. Great! 18:46:37 I'm seeing a lot of fluctuations between commits that don't change anything. 18:47:00 I'm retesting and being extra careful about using the same base versions. 18:47:15 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 19:05:41 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 248 seconds] 19:08:03 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 19:23:16 but I think a simple change so that assign-tn-costs accounts for the loop depth of each reference will take care of the regressions. 19:28:23 AFAIR the old regalloc did pack TNs in deeper loops earlier than other TNs so that they ended up in registers more often. You took that out intentionally for the new one? 19:40:35 no, that's still there. 19:41:33 But the question is more complicated. What if a TN appears in deeply nested loops, but only to be read once and then spilled across two calls? 19:42:07 we currently have two independent pieces of information: the max depth at which the TN appears, and the sum of the costs associated with references to the TN. 19:43:16 but the latter doesn't take depth into account. Being live across a call costs 3 points, and a read is worth 1, regardless of their respective loop depth. 20:05:52 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Ping timeout: 264 seconds] 20:20:02 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 20:25:24 -!- heddwch [~yoshi@76.8.3.189] has quit [Quit: Leaving] 20:28:53 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 248 seconds] 21:21:24 sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 21:22:27 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 21:30:37 -!- abarch [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Read error: Operation timed out] 21:38:18 -!- milanj [~milanj@82.117.199.26] has quit [Read error: Operation timed out] 21:50:20 -!- prxq [~mommer@x2f6d42e.dyn.telefonica.de] has quit [Remote host closed the connection] 21:58:13 -!- leuler [~user@p548FA70C.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:10:05 -!- fisxoj [~fisxoj@dyn-129-97-41-253.dynamic.uwaterloo.ca] has quit [Read error: Operation timed out] 22:17:12 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 22:20:55 -!- sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 252 seconds] 22:21:15 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 22:21:37 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 22:23:59 milanj [~milanj@cable-178-148-10-101.dynamic.sbb.rs] has joined #sbcl 22:31:12 -!- milanj [~milanj@cable-178-148-10-101.dynamic.sbb.rs] has quit [Quit: Leaving] 22:34:33 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 22:45:42 I think I found the bug. I was adding conflicts between TNs in different storage bases, which would confuse the heuristic to guess which vertices will probably be spilled vs coloured. 22:48:26 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 23:06:45 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Quit: w/e. lab meeting ho!] 23:09:58 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 23:10:18 -!- fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has quit [Ping timeout: 268 seconds] 23:50:25 -!- segv- [~mb@95-91-240-222-dynip.superkabel.de] has quit [Ping timeout: 272 seconds]