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
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
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
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
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
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
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
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 :)
timotimo jnthn: ^ is this the absolute wrong approach? 22:05

Powered by Cro and the Raku® Programming Language.

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

Thank you!