Skip to content

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

Merged
merged 7 commits into from
Oct 2, 2018
Merged

Enable i686 as a Host Platform #19607

merged 7 commits into from
Oct 2, 2018

Conversation

Kaiede
Copy link
Contributor

@Kaiede Kaiede commented Sep 28, 2018

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

  • Building the stdlib on i686 relies on PR Add sextOrBitCast to conversions of Builtin.Word #19600, which affects ARM 32 as well.
  • Full support of building at the tip of development is still broken because of a recent change. In particular, the SILLocation static_assert recently added fires on 32-bit hosts at the moment.

Issues that are Out of Scope

  • There are still breaks in downstream projects (libdispatch, llbuild, etc).
  • LLVM doesn't know how to dynamically link certain ELF32 relocations: GOTOFF/GOT32 when operating as VM/JIT instead of a back-end. This will need to be fixed before the Swift PM will build/work.

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.
Copy link
Contributor

@jrose-apple jrose-apple left a 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.

@mikeash
Copy link
Contributor

mikeash commented Sep 28, 2018

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.

@Rostepher
Copy link
Contributor

The build system changes look sensible to me.

@jrose-apple
Copy link
Contributor

@swift-ci Please test

@jrose-apple jrose-apple self-assigned this Sep 28, 2018
@Kaiede
Copy link
Contributor Author

Kaiede commented Sep 29, 2018

@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.
@jrose-apple
Copy link
Contributor

@swift-ci Please test

@jrose-apple
Copy link
Contributor

@swift-ci Please test source compatibility

@swift-ci
Copy link
Contributor

swift-ci commented Oct 2, 2018

Build failed
Swift Test OS X Platform
Git Sha - eddecbf

@swift-ci
Copy link
Contributor

swift-ci commented Oct 2, 2018

Build failed
Swift Test Linux Platform
Git Sha - eddecbf

@compnerd
Copy link
Member

compnerd commented Oct 2, 2018

LGTM

@jrose-apple
Copy link
Contributor

The one failure in the source compat suite is pre-existing; merging.

@jrose-apple jrose-apple merged commit c3b1143 into swiftlang:master Oct 2, 2018
@jrose-apple
Copy link
Contributor

Thanks, Kaiede!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants