cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
Guest753 has quit [Quit: Client closed]
stkrdknmibalz has joined #pypy
lritter has quit [Ping timeout: 252 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 252 seconds]
yizawa has joined #pypy
dustinm has quit [Quit: Leaving]
dustinm has joined #pypy
<arigato> just to tell you, I've been trying to look into the ppc jit issue---it's probably invalid assembly code generated---but I may lack the motivation to go through nowadays
yizawa has quit [Quit: Connection closed for inactivity]
LarstiQ has quit [Ping timeout: 260 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 265 seconds]
ronan__ has joined #pypy
<arigato> cfbolz: seen in map-improvements-3.7: I'm not saying it is related to the crash, but I see that you're doing something that I *think* is not allowed:
ronan has quit [Ping timeout: 252 seconds]
<arigato> you can't convert the bytes of an integer to a float, pass it around as a float, and later convert back to an integer
<arigato> doing that was something that we tried to do in the JIT and found that occasionally some byte pattern doesn't round-trip correctly
<arigato> we fixed it by declaring all storage places as LONGLONG instead of DOUBLE, so that we'd always pass everything around as a long long instead, and convert the bytes of floats to long long and back
<cfbolz> arigato: hm, I thought I was doing it that way around
<arigato> I see an integer instance attribute that is read with the operations:
<arigato> f126 = getarrayitem_gc_f
<arigato> i127 = convert_float_bytes_to_longlong(i126)
<cfbolz> arigato: right :-(
<cfbolz> Ok, then the storage instead needs to be a longlong
<cfbolz> And the cast in other direction?
<arigato> yes, I see this:
<arigato> i139 = int_add(i127, 1)
<arigato> f140 = convert_longlong_bytes_to_float(i139)
<arigato> setarrayitem_gc(p124, 0, f140, descr=<ArrayF 8>)
<arigato> (that's for self.index = self.index + 1)
<cfbolz> Right
<cfbolz> Thanks
<cfbolz> Shouldn't be too hard to fix
<cfbolz> arigato: it's some NaN that breaks, I suppose?
<arigato> I think so
<cfbolz> arigato: what does the list strategy do?
<arigato> it stores a list of floats, but the difference is that it never tries to cast a random 64-bit integer to a float
<arigato> instead, it limits itself to 32-bit integers and casts them into special NaN values, which seems to be preserved
<arigato> I'm honestly not sure about the rules
<arigato> ...no wait
<arigato> no, it stores a list of longlongs, sorry
otisolsen70 has joined #pypy
<cfbolz> arigato: right, make sense
<cfbolz> But using the NaN bit patterns
<arigato> yes
<arigato> ah ha, getting there on the ppc bug
<cfbolz> Nice
<arigato> yep, it's one of the many places where "self.index = self.index + 1" gets inlined, which ends up writing a bogus value
ronan__ is now known as ronan
<cfbolz> arigato: ouch
<cfbolz> Sorry :-(
<cfbolz> arigato: I can fix it, but probably only tonight or tomorrow
<arigato> no problem. as I said I don't know if that's the problem
<cfbolz> arigato: sounds plausible at least
<arigato> not really
<arigato> because the values look like "4" instead of "19"
<cfbolz> :-(
<cfbolz> And NaNs are more complex
<arigato> yes
<arigato> ah, no, I think I see the bug
<arigato> pff rare cases
<arigato> cfbolz: so handling many more floats than before just made the ppc bug slightly less rare
<cfbolz> arigato: right
<cfbolz> arigato: like the register allocator getting pushed too much?
<arigato> it's in jump.py, the register movement logic at the end of the trace
<arigato> the ppc variant only
<arigato> it calls regalloc_push/regalloc_pop for the cases where it needs to push/pop stuff temporarily on the stack
<arigato> but in ppc you need to pass in an index in case you push several ones
<arigato> of course it can occur that two different places in the code both pass index 0
<cfbolz> arigato: ouch
<cfbolz> arigato: do the random tests not stress that?
<arigato> I guess not enough?
<cfbolz> Right
<arigato> they should, but it takes quite some bad luck to get into the case
<arigato> can't try to run it more, py.test crashes for me on ppc
lritter has joined #pypy
<arigato> in case anyone wants to fight py.test, the traceback is: https://pastebin.com/1tZVrAV3
Julian has joined #pypy
<cfbolz> :-(
<cfbolz> arigato: we should fix the float storage anyway to be safe, right?
<arigato> probably
<arigato> also because convert_float_to_longlong operations in the JIT are not completely free
<arigato> so better make integers avoid it
<cfbolz> arigato: good point
<cfbolz> (we should be able to fuse getfield & cast to different getfield in the backend some how)
Julian has quit [Ping timeout: 252 seconds]
slav0nic has joined #pypy
Julian has joined #pypy
<tumbleweed> arigato: well done finding the PPC JIT bug, that looks about as gnarly as I expected it to be
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
lritter has quit [Ping timeout: 260 seconds]
stkrdknmibalz has joined #pypy
Ben10 has joined #pypy
Julian has quit [Quit: leaving]
Ben10 has quit [Quit: Client closed]
Ben10 has joined #pypy
Ben10 has quit [Ping timeout: 256 seconds]
trace987 has joined #pypy
<trace987> how to debug if python3 and pypy3 bring different results?
otisolsen70 has quit [Quit: Leaving]
Julian has joined #pypy
Julian has quit [Quit: leaving]
trace987 has quit [Ping timeout: 260 seconds]
trace987 has joined #pypy
slav0nic has quit [Ping timeout: 260 seconds]