Upgrade to LLVM 4.0

[shepmaster]

The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible.

This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems:

• DIDescriptorFlags became a real C++ enum and not a bitset (#37857)
• An EH personality is required for every function that can unwind (#37862)
• AlwaysInliner pass changed header and constructor name (#37861)
• createBasicType changed API (#38317)
• Bitcode/ReaderWriter.h has been renamed / API changed (#38156)
• powidf2 / powisf2 calling convention changed (LLVM 31685)
• llvm::AttrBuilder changed API (#37831)
• DIBuilder::createNameSpace changed API (#38000)
• LLVMRustPrintPasses prefers StringRef over char * (#38027)
• OptimizationDiagnostic string type changes (#37982)
• llvm::StringRef is not guaranteed to be null terminated (#38048)
• getPassName changed return types (#38195)
• Archive support changed error handling types (#38196)
• Teach Rust about an LLVM 4.0 API change for creating debug info
  for global variables (#38295)
• Check all errors in LLVMRustArchiveIterator API (#38676)
• Upgrade emscripten (emscripten-core/emscripten-fastcomp#165, emscripten-core/emscripten-fastcomp-clang#13)
• Alignment now represented with 32 bits instead of 64 (#39529)
• DIBuilder::createGlobalVariable API changed again (#39528)
• llvm::DIBuilder::createCompileUnit now takes an llvm::DIFile* instead of a Filename and Directory (#39747)
• Symbol lookup error when linking dylibs (#39782)
• Undefined behavior in repr(packed) tests (#40373)
• Unoptimised builds of compiler_builtins on ARM have references to core::panicking::panic (#40508)

---

A WIP PR that performs the upgrade! #40123

---

Some issues whose resolution is believed to be blocked on LLVM 4.0:

• #39015

[brson]

Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.

[rkruppe]

For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now. I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC (rkruppe) or via mail!

[TimNN]

Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets:

https://llvm.org/bugs/show_bug.cgi?id=30543

I'm explicitly mentioning this here, because there were previously problems with it, see #37559 and related issues. Also cc rust-lang-nursery/compiler-builtins#116, an issue about the same problem in the compiler-rt rust port.

[alexcrichton]

To clarify what I think the @TimNN is referring to (correct me if I'm wrong)

• In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention
• In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention
• One person claims that aapcs is expected for powis2f and powid2f, while another cites a different thread claiming that the normal C calling convention should be used.

So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition.

This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...

[shepmaster]

and I'd love to coordinate

@rkruppe Any objections to doing that coordination here on GitHub, or on one of our forks?

[rkruppe]

I don't have strong preferences for the communication channel.

[rkruppe]

#37831 should address what is listed as "AttrBuilder API changes" above (the core of the change is in how attributes are represented).

[rkruppe]

@shepmaster I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, avr-rust@3e1e4a4 looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and avr-rust@c32f9c1 looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)

[shepmaster]

@rkruppe Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.

[rkruppe]

@shepmaster Awesome, thanks in advance!

[rkruppe]

BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of #37831

[Kixunil]

Does anyone have ETA? I'd like to know when I can use AVR. :)

[dsvensson]

@shepmaster @dylanmckay So whats the next issue(s) to subscribe to in the race-to-AVR? :)

[dylanmckay]

As @shepmaster says on reddit, we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting libcore compiling for AVR.

Once that is working, we could then start looking into upstreaming the AVR target to Rust.

[shepmaster]

So whats the next issue(s) to subscribe to in the race-to-AVR?

AVR-specific issues can be raised / tracked in https://github.com/avr-rust/rust

For example, there are two that I'm aware of right now:

• avr-rust#26
• avr-rust#27

[BatmanAoD]

#39782 has been closed, so that can be checked off in the top post.