Support for 32-bit CPUs

[Finagolfin]

@compnerd

Likewise - I'm simply suggesting that this might be an easier thing to accomplish and perhaps easier to run. That is, I'm simply pointing out an alternative approach which might hopefully be less time consuming on the CI runs (if it is more time consuming, we should not go down this path).

OK, I wasn't sure what you were getting at, since you didn't mention the CI in your prior comment.

It all depends on what kind of time we are trying to conserve. Android would be the easiest to configure, since we already have the 32-bit Android armv7 tests running. However, I'm guessing that adding running the 32-bit Windows x86 tests on every compiler pull would add the least CI runtime.

Adding running the 32-bit watchOS tests to every macOS smoke test on the PR CI would likely minimize both configuration and CI runtime, but for whatever reason that doesn't appear to be a public CI now.

@John_McCall

I don't think 32-bit Android is likely to end up as one of the mandatory CI platforms

This isn't about making 32-bit Android mandatory as much as making some 32-bit platform mandatory for compiler pulls, for which I'm suggesting Android armv7 as one possible candidate.

@John_McCall

so we'd still be waiting for other bots to run.

Not sure what you mean, you don't want to make pull authors wait longer? One advantage of adding Android is that it's a whole new separate CI job that completes much quicker than the others right now, so it would likely always finish first, at the expense of more CI minutes used than simply testing an incremental SDK like 32-bit watchOS.

[Finagolfin]

@Finagolfin

@mishal_shah and @kubamracek, what do you think about adding the Android CI as a requirement for compiler pulls on the main branch in the github UI, primarily to make sure most of the compiler tests pass for a 32-bit architecture? I am not worried about 64-bit Android, which we can always fix tests for as issues arise, but in the couple weeks since the official Android CI has been going, it has proven to be a good canary for compiler tests that don't pass for 32-bit arches.

I'd like to repeat the request for a 32-bit compiler validation test suite run before Swift compiler pulls are merged, rather than afterwards as is the status quo. This would notify test authors early on that their pull fails on 32-bit, so they can either disable 32-bit runs in their tests or add that support.

I bit the bullet since the Android CI was added last year and have it running the 32-bit Android armv7 compiler validation suite for the host, ie non-executable, tests, reporting any 32-bit test failures I see after pulls are merged. This is in addition to the internal 32-bit watchOS armv7k CI that is also occasionally run and used to flag tests to update for 32-bit later.

If we're serious about 32-bit support for Embedded, we should have some 32-bit platform continuously run through the compiler validation suite before all compiler pulls are merged, though of course that will give wider 32-bit coverage than the Embedded Swift subset uses. Ideally, it would be a 32-bit platform that supports running the executable tests too, which would currently rule out Android armv7 (we don't have the Android emulator set up on Jenkins CI yet, so the 5-7% of executable tests are not run for Android).

Would elevating 32-bit watchOS armv7k on the newly-required macOS arm64 PR CI be a good candidate? I don't care which 32-bit platform is made mandatory for compiler pulls before merging, but would be good to add one finally.