Drop x86 (32bit) JIT backend

# Yusuke Suzuki (5 days ago)

Hello all,

Now, Xcode no longer has ability to build 32bit binary. Fedora starts dropping x86 32bit kernel shipping. Our x86/x86_64 JIT requires SSE2, so such CPUs can use JIT if they want by switching x86 to x86_64. And these CPUs are modern enough to run CLoop at high speed.

x86 32bit JIT backend is very complicated and is being a major maintenance burden. This is due to very few # of registers. Which scatters a lot of isX86 / CPU(X86) in Baseline, DFG, and Yarr. I’m now planning to optimize some part of Yarr, but x86 YarrJIT is being a major barrier of such cleanups / optimizations.

So, I would like to propose dropping X86 32bit JIT support.

Contact us to advertise here
# Geoffrey Garen (5 days ago)

No objection.

Geoff

# Yusuke Suzuki (5 days ago)
# Yusuke Suzuki (4 days ago)

Thanks!

I think we are not testing x86 JIT configuration, and nobody is seriously using it (Default build option for c86 is no JIT). Removed :D

Best

# Xan (2 days ago)

We at Igalia use the x86 32bit port for testing, prototyping, etc, in our 32bit work. We recently added a JSC EWS x86 instance. That being said only the LLInt tier is working properly at the moment, and if the maintenance of the JIT code is a big burden we think it makes sense to remove it.

This already happened during the weekend, so I guess this can count as an after the fact tacit agreement. In the future we'd appreciate if we could have at least a full week day (including Europe) to discuss these kinds of changes though.

# Yusuke Suzuki (2 days ago)

Thanks!

On Sep 16, 2019, at 4:39 AM, Xan <xan.lopez at gmail.com> wrote:

Hi all,

We at Igalia use the x86 32bit port for testing, prototyping, etc, in our 32bit work. We recently added a JSC EWS x86 instance. That being said only the LLInt tier is working properly at the moment, and if the maintenance of the JIT code is a big burden we think it makes sense to remove it.

Yes, x86 adds many special logic. You can see the actual diff, which involves many “only for x86” logic involving weird stack push/pop. And it is not well-abstracted. As a result, changes are in all of our JIT tiers (except for FTL b/c we are not supporting x86 in FTL) :( trac.webkit.org/changeset/249880/webkit, trac.webkit.org/changeset/249880/webkit

YarrJIT has HAVE_INITIAL_START_REG ifdef and separate logic, which is only for x86. All the other platforms including ARMv7 do not require this. If this architecture has enough # of registers (like, MIPS), keeping it would be much easier. But it only has very few registers and this makes x86 special compared to the other 32bit architectures. I also note that x86 JIT is not working for at least 3 months. I found that x86 callee-save-register definition is broken at some point[1].

[1]: trac.webkit.org/changeset/249830/webkit, trac.webkit.org/changeset/249830/webkit

This already happened during the weekend, so I guess this can count as an after the fact tacit agreement. In the future we'd appreciate if we could have at least a full week day (including Europe) to discuss these kinds of changes though.

OK, I see.

Want more features?

Request early access to our private beta of readable email premium.