00:00 timo1 joined
timotimo i don't really know how i'd hook it up later, but i think i'll write a function that'll take an MVMString and hash it with the uthash function we're using even if it's a ropey string or an 8 bit string 01:39
01:49 jnap joined 01:56 btyler joined
timotimo should just be a manner of manually unrolling the loop for 4 iterations and pretend the bytes we got into it were actually MVMint32 rather than MVMuint8 01:56
that would give three zero bytes that i should be able to manually "partialle evaluate" 01:57
01:57 jnap joined
timotimo though ... the compiler could do that for me, too ... and it would be easier to maintain if it'd just be a straight copypaste from the original algo 01:57
02:16 raiph joined
timotimo oh, of course the hash function that is used is the one with the largest amount of code ... 02:20
i'll go to bed before i tackle this 02:21
JimmyZ good night 02:37
02:58 jnap joined 02:59 woosley joined 03:43 hoelzro joined 03:58 jnap joined 04:31 eternaleye joined 04:59 jnap joined 05:28 flussence joined 06:00 jnap joined 06:53 eternaleye joined 07:01 jnap joined 07:08 zakharyas joined 08:38 brrt joined 09:02 jnap joined 09:48 ilbot3 joined 09:54 hoelzro joined, yawnt joined 09:56 japhb_ joined 09:57 bcode joined 10:03 zakharyas joined, japhb_ joined, rurban_ joined 10:04 woolfy joined, timotimo joined 10:06 TimToady joined 10:08 sergot joined 10:15 tokuhirom joined 10:26 masak joined 10:27 jnthn joined, vendethiel joined, lue joined, retupmoca joined, colomon joined, FROGGS joined, japhb_ joined, eternaleye joined 10:28 japhb_ joined, camelia joined, woosley joined 10:29 flussence joined 10:30 brother joined 10:34 JimmyZ joined 10:39 masak_ joined, cxreg joined 10:40 daxim_ joined, dalek joined 10:45 dagurval joined 12:20 tokuhirom joined 12:21 zakharyas joined, rurban_ joined, flussence joined 12:22 japhb_ joined 13:15 raiph joined 13:40 benabik joined 13:54 btyler joined 14:11 jnap joined 14:32 jnap joined 14:45 chipdude joined, TimToady joined 14:49 brrt joined 14:50 nwc10 joined
timotimo wval r2(3), liti16(1), liti16(8) 16:32
eqaddr r3(1), r1(3), r2(3)
this should work well, right?
jnthn yeah, should 16:33
timotimo wval r2(6), liti16(1), liti16(13)
getattr_o r5(1), r4(3), r2(6), <nyi(lit)>, liti16(3)
got a clue why this getattr doesn't get specialized? 16:34
oh, in the other case it does get specialized
not in the theoretically unreachable block, though 16:35
timotimo hacks
jnthn We don't do getattr spesh yet
As in, p6opaque doesn't implement doing that yet
It's actually a bit tricky 'cus you have to cope wiht attr auto-viv
timotimo ah
eqaddr warrants its own optimize_ function, eh? 16:36
jnthn yeah 16:37
timotimo github.com/MoarVM/MoarVM/blob/spes...ize.c#L103 ← should this really be operands[1]? i think it should be operands[0] instead 16:40
jnthn ooh! 16:41
*that's* why it breaks if we uncomment it!
timotimo++
timotimo :D
timotimo changes and commits
dalek arVM/spesh: 6b79a76 | (Timo Paulssen)++ | src/spesh/optimize.c:
isconcrete spesh used to clobber object values. now it should work
 16:42
timotimo copy&paste programming saves the day %) 16:43
hmm. Cannot add a null method 'unshift' to class 'NQPArray' 16:44
apparently that fix was not enough 16:46
timotimo doesn't see anything else that'd be wrong 16:48
i'm sad to say i'll still have to comment out isconcrete :\ 16:51
dalek arVM/spesh: 57010dc | (Timo Paulssen)++ | src/spesh/optimize.c:
isconcrete still causes breakage unfortunately.
 16:52
timotimo how do you feel about adding a "special character" to the spesh log env var to have the file be opened "wa" instead of "w"? 16:53
jnthn hmm 16:57
feels like a smelly way to do it...
timotimo i suppose on linux i could mkfifo and drain that into a file to get the same effect 16:58
aye, eqaddr did not do anything yet 17:07
17:17 cognominal joined
timotimo jnthn: could the reason you identified before have to do with decont/cont status? 17:17
actually ... these are not containered it seems 17:20
gist.github.com/timo/e031ed9cc1ad94b2d092 - this is the before of "method returns" for example
you can see in lines 18f the value to compare against gets put into r1
then in 28 r2 is filled with the value to compare against (or the other way around?) 17:21
and they are immediately eqaddr'd
oh, oops
this is the version that gets an actual value passed %) 17:22
jnthn oh :)
no, I think it may have been a phi issue
timotimo f5 to see the after of a version where a value gets passed
do we forget to remove phis from blocks that have shriveled and died? 17:23
block removal is the last phase of the pipeline at the moment, so that'd be a little problem
jnthn Well, the thing about PHIs is that they make information propagatoin tricky 17:28
timotimo yeah :\
jnthn But in this case it is the degenerate case, iirc, where there are two paths and one of them dies.
timotimo thought so 17:29
IMO, these getters/setters are kind of juicy targets :) 17:39
am i wrong?
jnthn they are 17:41
timotimo jnthn: do you have a clue how to properly make the special string hashing functions (well, defines really) known to uthash? 17:57
it bothers me quite much that we have to blow up every string to 32bit integers
jnthn timotimo: I was pondering taking that on in the string re-work... 17:58
It's...not quite trivial.
timotimo the obvious way is to make a "key extractor" that does the expansion, but that would be almost as bad as what we have now 17:59
jnthn Well, the trick is not to expand it but pretend you read 3 0s and factor them in per byte
timotimo the other way would be to re-write the hash function dividing the indices by 4 and if they are not %% 4, they are 0 (to emulate the 32 bit long number)
yes
jnthn whihc means hacking the hash function
and WORSE, you gotta do it endian sensitive
timotimo i've looked at it. it was intimidating at first, but now it seems less threatening
that's the part that really gets me 18:00
the endian sensitiveness
i would think we can rely on the compiler to do a lot of work at compile time and only change very little of the actual code
jnthn oh, it's just if you do the zeros before of after the byte 18:02
timotimo OK, so in theory i could copypaste the hash function we're using 18:03
replace all key_access[index] with get_byte_at_small_key(index)
and depending on the endianness, implement get_byte_at_small_key as return 0 if index %% 4 else return key_access[index / 4]
or ... whatever the other thing would be ... i guess index % 4 == 3 or something?
jnthn guess something like it 18:05
timotimo time to find some documentation on endianness, i suppose?
well, actually it'd just be flipped
so i suppose that'd be easy to do
timotimo goes to the whiteboard
since the uthash code is just plopped in in-line, i'm thinking the macros could get an extra parameter that you can set to a local variable (or constant value) to decide whether to use the expanded or the non-expanded hash 18:07
i'm glad i don't have to hack around with two's complement at all in this case 18:17
well, i've got *some* code now ... 18:35
dalek arVM/uthash_padding: 342ecc2 | (Timo Paulssen)++ | 3rdparty/uthash.h:
maybe we can hash uint8 strings with padding like this...
 18:36
arVM/uthash_padding: 3f1ab87 | (Timo Paulssen)++ | 3rdparty/uthash.h:
this is how you C.
 18:43
18:46 cognominal joined
japhb ♪♫ This is how we do it ♪♫ 19:00
timotimo so many places to patch >_< 19:09
this should have suggested to me it's the wrong approach long ago, but whatevs ...
dalek arVM/uthash_padding: 846d59e | (Timo Paulssen)++ | src/ (13 files):
this is much work; may be a dead end even.
 19:12
19:12 brrt joined
dalek arVM/uthash_padding: 58a2806 | (Timo Paulssen)++ | / (4 files):
the last HASH functions that are used are now guarded.
 19:20
timotimo and of course it immediately explodes :)
19:30 lizmat joined 21:13 lizmat joined, woolfy joined 21:26 brrt left 21:43 woolfy joined
timotimo jnthn: ^ is this the absolute wrong approach? 22:05
22:14 odc joined 22:15 woolfy joined 22:19 lizmat_ joined 22:25 lizmat joined, woolfy joined 22:26 woolfy left 22:52 woolfy joined, woolfy left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!