Discontinue support for IA32 architecture

[alexmarkov]

IA32 architecture is somewhat special in Dart VM:

• AOT compilation is not supported on IA32.
• Type testing stubs are not supported on IA32.
• Due to a small number of registers, IA32 often has a custom implementation of various stubs or custom code generation patterns which are sufficiently different from other architectures.

Supporting IA32 carries additional burden when adding new features. At the same time, usage of IA32 declines over time.

We should consider if it is still useful to support IA32 architecture in the future versions of Dart, deprecate and eventually drop IA32.

/cc @mit-mit @a-siva @mraleph @mkustermann

[mit-mit]

cc @Hixie @tvolkert any known big Flutter uses of this?

[aam]

I thought android simulator used for internal testing only supports x86

[a-siva]

I thought android simulator used for internal testing only supports x86

The last time I checked it seemed like they were all migrating to use x64 simulators, maybe @xster has more information on this.

[tvolkert]

/cc @zanderso

[zanderso]

@a-siva right, AFAIK we're only keeping support for IA32 around for internal simulator testing. We can start the process to drop it as soon as it's no longer needed there.

[Hixie]

cc @khyati82

[Hixie]

(I'm fine with removing IA32 support.)

[mraleph]

It does seem that there is some dependency on IA32 target (e.g. on Windows) and some companies maintaining it as a target outside of Flutter tree, see comments on flutter/flutter#37777

I think we could try to find a way to keep IA32 alive, but potentially not very performant.

[khyati82]

Based on IA32 usage internally, we are going to revisit this issue once that migration is done.

[athomas]

Given that it seems unlikely that we will invest in adding support for Windows IA32 to Flutter based on the linked issue, is it really worth it to carry around this support in Dart? Assuming someone still needs to use Dart on Windows IA32, they can continue to use old versions until they are ready to upgrade. If you're on Windows XP/IA32 (one comment on the thread mentions Windows XP being widely used by their customers), you're already using old versions of most other software.

[parlough]

From the linked issues, it sounds like many of the custom usages of IA32 in Flutter were also using Windows 7 which support for is also likely being dropped (#54509), perhaps it's time to reconsider this.

It seems support is eating in to engineering time recently beyond having to implement new functionality/changes on the extra backend target: (#54487, #47177, #54290, etc).

Does the internal Android simulator support still require this?

[a-siva]

Does the internal Android simulator support still require this?

@jiahaog or @CaseyHillers any ideas about whether internal usage of Android Simulator has all been migrated to use the x64 version?

[jiahaog]

It seems like we have a way forward internally to move to x86_64. I filed b/321123479 internally to track it. @a-siva is there a particular timeline we're looking at here?

[a-siva]

It seems like we have a way forward internally to move to x86_64. I filed b/321123479 internally to track it. @a-siva is there a particular timeline we're looking at here?

@jiahaog we don't have a firm timeline for it. The general sentiment is to deprecate support when it is feasible.

[ganenkokb-yandex]

@mraleph You mentioned that it is planned to completely remove the ia32 support code. Are there any real plans for this? If there are tasks in the work for this, could you link them to make it easier to track the status?

[mraleph]

See @a-siva's comment above. No concrete date for removal, yet. This issue will be updated when we actually start removing it.

But I think we can already declare it deprecated - meaning that we are not planning to do any (large) changes to the IA32 backend (like implementing AOT for example).

@a-siva @mit-mit Should we make this explicit in the list of supported platforms that IA32 is effectively frozen? We will fix bugs, but not add new functionality.

[mkustermann]

We have known internal uses that keep ia32 alive (b/321123479), though are there any real external use cases we need to support?

If not, I suggest we simply stop distributing our ia32 Dart SDK externally - today!

The only external use case I can see that makes sense is to use ia32 to get lower memory consumption compared with x64 when running on intel devices. If that's a real use case, we may consider distributing a x64c Dart SDK instead (i.e. x64 with compressed pointers).

[parlough]

though are there any real external use cases we need to support?

It seems they were mostly using W7 which support was already dropped for in 3.4 dev builds, so I doubt there are too many. I suppose there might be some IA32 Linux users?

If not, I suggest we simply stop distributing our ia32 Dart SDK externally - today!

Makes sense to me, at least for Windows. I think we should at least continue to surface any 3.3 stable patch releases to be consistent, but if someone wants to open a breaking change issue and announce to the Google group a formal discontinuation of the builds in 3.4, I'd be happy to make adjustments to the website's archive and supported platform list for the next release.

[a-siva]

If not, I suggest we simply stop distributing our ia32 Dart SDK externally - today!

Not sure if this is going to make a difference, also considering that flutter imports a prebuilt dart SDK for building flutter apps internally this may not be feasible (similar to why we could not drop legacy mode from the external Dart SDK).

I feel once b/321123479 is addressed we should drop support.

I agree that we should probably make it explicit that support for ia32 is on the path for deprecation soon and only critical issues will be fixed

[jiahaog]

I just realized that internally we have a small number of clients who are shipping x86 JIT builds on Android (https://github.com/flutter/flutter/wiki/JIT-Release-Modes). We will need to get in touch with them to figure out a way forward. (Will track this in b/321123479 as well)

[a-siva]

based on a conversation with @jiahaog the following action items came up

• Apparently flutter testing in luci uses x86 emulators, these need to be switched to x64 android simulators?
• add a warning in flutter tools to have users use the x64 android emulator and indicate support for running on x86 android emulators is being deprecated.
• the jit release x86 mode needs to be deleted from flutter engine sources

[a-siva]

Breaking change request has been filed here #59698