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 | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
jcea has quit [Ping timeout: 252 seconds]
itamarst has quit [Quit: Connection closed for inactivity]
nightstrike has quit [Quit: Connection closed for inactivity]
jcea has joined #pypy
nightstrike has joined #pypy
nightstrike has quit [Quit: Connection closed for inactivity]
jcea has quit [Ping timeout: 248 seconds]
<korvo> When it comes to jitcode generation, I've been told to let it be Somebody Else's Problem; the JIT generator will trace my interpreter and dynamically produce the jitcodes that will be included. Is there any advice on going the other way and ensuring that an interpreter will always generate certain jitcodes?
<korvo> As a hopefully silly example, suppose that some backend has a floating-point sine operation. (We do this one in software IIRC, so just for illustration.) We might want to know at translation time whether a given interpreter is going to use that operation.
<korvo> I know that there's infrastructure for the case of vectorized operations, supporting autovec, but I don't know how that interacts with jitcodes.
<cfbolz> 1) autovectorization is always disabled, it has bugs that we never found 2) no, we don't really track what kind of specific instructions the current cpu supports
steeznson has joined #pypy
jcea has joined #pypy
steeznson has left #pypy [ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)]
itamarst has joined #pypy