-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Enable i686 as a Host Platform #19607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Prior to this, the swift build didn’t understand what i686 is, or what to do about building it. This unblocks building, but will still run into build breaks.
A static assert fires around GenericContext not quite being the correct size for 32-bit. Aligning _GenericContext addresses this problem. swift/include/swift/AST/Decl.h: 1541 static_assert(sizeof(_GenericContext) + sizeof(DeclContext) == 1542: sizeof(GenericContext), "Please add fields to _GenericContext");
There’s a few places where size_t is used for a field/parameter when constructing an array for types. Unfortunately, the Bitfields that were backing the inputs to these at some point after 4.1 grew past 32 bits and are now backed by a uint64_t. Even though the slice of the bitfield is small enough for 32-bit, clang sees these slices as 64-bit and complains if there isn’t a cast involved.
Darwin and Linux use different size and alignments for “long double” on 32-bit x86. Instead of hardcoding it, we should just ask LLVM about it.
Win and Linux Arm32 have the same aversion to linking compiler-rt for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compiler-side changes look good. @stephentyrone and @mikeash can check the stdlib parts, and @Rostepher, @zisko, and @compnerd are probably good for the CMake and build system parts.
Stdlib bits look OK. Not a whole lot to see there. The rest looked good too as far as I could tell, but I don't know those areas as well. |
The build system changes look sensible to me. |
@swift-ci Please test |
@jrose-apple Sorry, but can you take a look at the SILLocation assert change? I didn't get a good chance to see what was up with it until now, and I'm not 100% confident this is the approach you'd want here. But it would be nice to get that fix in at the same time. That way, this PR and #19600 are effectively everything needed to get master building on i686, at least as of when I pulled into my fork yesterday. |
The assert currently assumes that the size of SILLocation is 3 pointers big, or 24-bytes as it is on 64-bit platforms. The catch is that this math works because it’s having to make a rough assumption of the size of unsigned and pointer in relation to each other. 4 unsigned + 1 pointer = 3 pointer in this example. This breaks down on 32-bit where 4 unsigned + 1 pointer = 5 unsigned = 20 bytes. It technically doesn’t violate the spirit of the assert, but the way the assert is written simply doesn’t work for 32-bit. It can be written as `sizeof(SILLocation) <= 6*sizeof(unsigned)` without an ifdef, but it means that if someone was to make it even smaller at some point, the assert wouldn’t fail, signaling to the developer that they should update the assert with the new, smaller, value. But it would be cleaner. The way this change is written, if the size changes in either direction, the developer is signaled that they should either update the assert, or fix their regression.
@swift-ci Please test |
@swift-ci Please test source compatibility |
Build failed |
Build failed |
LGTM |
The one failure in the source compat suite is pre-existing; merging. |
Thanks, Kaiede! |
This is a set of changes that is aimed at enabling Linux i686 as a host platform for Swift. The reason behind this is to make it possible to use i686 as an analogue for other host platforms (Arm32), making investigation into 32-bit specific issues easier by being able to do the work on more powerful hardware where builds can easily be a quarter of the time.
As a side effect, once other issues are also addressed, it would enable a new class of hardware to be used for Swift. It would also enable something like Debian and/or Ubuntu on 32-bit x86 to be a CI analogue for ARM32 Single Board Computers, which are popular, cheap, but very slow to build and report results.
Each change is split to make the set easier to understand, and any comments about why a particular change was made the way it was should be available in the description of that change.
The two changes marked with "[32-bit Linux]" also affect ARM 32 hosts (Raspberry Pi), and are regressions that happened after 4.1, and currently impact 4.2 and master.
Remaining Issues
Issues that are Out of Scope