Index

Show enters and exits. Hide enters and exits.

19:14:25evanbrixen: pretty sure i've got the XSS problem fixed.
19:14:32evanhad to do a pretty major modification to onig though.
19:15:51brixensweet
19:17:00DefilerThere's probably no API to hook into with Terminal if I want to listen for certain events
19:17:18evanDefiler: ?
19:17:24DefilerI'd like to do something better with the shift-cmd-click event
19:29:43boyscoutTeach onig to treat invalid utf-8 sequences are raw bytes - 765ee2f - Evan Phoenix
19:38:09boyscoutCI: rubinius: 765ee2f successful: 3449 files, 13484 examples, 41048 expectations, 0 failures, 0 errors
21:32:18dbussinkevan: how was the vacation?
21:49:59slavahi evan, brixen
21:58:12evanslava: hello.
21:58:15evandbussink: oh, good.
21:58:24evani was a little sick the whole time, which sucked.
21:58:26evanbut it was fun.
21:59:20dbussinkevan: ah, that's too bad then yeah
21:59:28dbussinkevan: still feeling a bit ill now?
21:59:40evana little, yeah.
21:59:46evani had a low fever yesterday
21:59:58evanif it flares again, i'm going to go into the doctor
22:00:07evansince i'll probably need to get some antibiotics
22:01:26slavaevan: are you going to add some float optimizations soon? floats are easier to make fast than fixnums
22:01:32slavabecause the result of a float op is always a float
22:01:42evani've started to yeah
22:01:50evanprobably when I upgrade to LLVM 2.7 i'll do that
22:02:08evanbecause i'll use it's new metadata stuff to do some type based alias analysis
22:02:17evanto remove float boxes
22:02:30slavacool
22:02:38slavado you think eventually you'll allow values to live across a GC?
22:02:52evanwell, how do ya mean?
22:03:16slavawhen you have a GC check, and some values are in registers, what happens?
22:04:11evani force LLVM to reload them out of the storage that the GC can see
22:04:12evanbasically
22:04:22slavadoes LLVM know its the same value?
22:04:29evanno, thats part of the issue
22:04:36evanbut with the metadata stuff
22:04:50evani'm going to propagate the type info between SSA variables that hold the same value
22:04:57evanie
22:05:10evanval = stack[0]; whatever(val); val2 = stack[0]
22:05:28evanwell, it's more like
22:05:33evanval = stack[0]; whatever(stack, val); val2 = stack[0]
22:06:01evani know that whatever can stack by moving objects, but it won't change the type
22:06:08evancan change the stack, rather.
22:06:24slavaok
22:06:29evanthe data still has to be reloaded from val2 though
22:06:34slavais there a way of doing it without saving the value to the stack?
22:06:35evanin certain cases
22:06:45evanie, if i've unboxed val into a double on the stack
22:06:49evani don't need to unbox val2
22:06:59evansince I know that val2 will have the same double
22:07:17slavain that case you don't have to pass it to the GC at all
22:07:24slavaonce its been unboxed you don't need to hold on to the boxed version anymore
22:07:27evanwhats it?
22:07:44evansure, thats another optimization
22:07:58evanif you can reason that the box isn't used at all
22:08:07evanhopefully you avoided creating the box in the first place
22:08:11evanmuch bigger win there.
22:11:44slavaare you able to keep values in registers across method calls?
22:12:49evanno, how could you?
22:13:01evanunless I'm able to have something that can update the registers directly
22:13:16slavawell, LLVM would spill the registers for you
22:13:26evanright, spill and reload them.
22:13:28slavathis would be more efficient than shuffling everything to the operand stack
22:13:38evanthis being what?
22:13:55slavaletting LLVM save/restore registers instead of doing it yourself on the operand stack
22:14:13evanthats what i'm doing now.
22:14:18slavacool
22:14:19evanyou're saying something else would be better
22:14:23evanaren't you?
22:14:35slavaso you have GC metadata for LLVM?
22:14:43evanone thing at a time.
22:14:51evani do use an explicit operand stack
22:14:56evanthat values are read and written to
22:15:08evanLLVM can optimize access to it already, ie:
22:15:26evanstack[0] = val; val2 = stack[0];
22:15:34evanit will replace val2 with val
22:15:39slavabut not if there's a call in between
22:15:42evanacross GC points though
22:15:48evanit will reload the values from the operand stack
22:16:09evanwhich is fine, because thats exactly the same as reload them as though they were spilled registers
22:16:29evanthe operand stack is the equiv of an alloca()
22:16:39slavaif a value passes through a GC check like this, can LLVM still do LICM and such?
22:16:44evanso LLVM can access it via the frame pointer
22:17:13evanslava: it must assume nothing about the pointers in the operand stack across a GC point
22:17:16evannor should it.
22:17:22evanthey could all be moved
22:17:38evanand LLVM's alias analysis is pointer based
22:17:55evanso it's just concerned with knowing if to SSA variables are for the same address in memory
22:18:08evanthats why I have to build type based alias analysis on top
22:18:13slavabut normal spilling has the advantage that its done late
22:18:16evanwhich I can maintain across GC points
22:18:16slavaso it doesn't ruin other optimizations
22:18:34evanin this case, it's the same.
22:18:53slavaif a value is a tagged fixnum 1 before a GC point will it know its the same after?
22:20:47evanit can in some cases
22:20:54evanand actually, i could teach it that now
22:21:13evanor, rather, teach it better about that.
22:21:31evani already improve on it's AA data by detecting and return strong alias info about tagged pointers
22:21:38evanwhich improves all optimizations
22:25:31evanok, bbiab.