LLVM error while cross-compiling Servo for ARM

The profile_csv3 branch compiles successfully on a Mac OS X 10.10 and on a 64-bit Ubuntu 14.04. However, while cross-compiling the profile_csv3 branch for ARM (following instructions here: https://github.com/servo/servo-nightly/blob/master/.travis.yml) using the arm-linux-gnueabihf toolchain on an Ubuntu (14.04/15.10) host, I get the following error:

rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp:531: void {anonymous}::PromoteMem2Reg::run(): Assertion isAllocaPromotable(AI) && "Cannot promote non-promotable alloca!"' failed. Aborted (core dumped) Build failed, waiting for other jobs to finish... Could not compileimage`.

Servo branch: https://github.com/larsbergstrom/servo/tree/profile_csv3
Environment variables set:
BUILD_TARGET=arm-unknown-linux-gnueabihf
TRIPLET=arm-linux-gnueabihf
PKG_CONFIG_ALLOW_CROSS=1
PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig
EXPAT_NO_PKG_CONFIG=1
FREETYPE2_NO_PKG_CONFIG=1
FONTCONFIG_NO_PKG_CONFIG=1
CC=arm-linux-gnueabihf-gcc
CXX=arm-linux-gnueabihf-g++
PATH="$PATH:$HOME/bin"

[rzambre]

I posted this issue. I had to delete my old account.

[larsbergstrom]

You can see this by compiling the image crate version 0.7. Note that it only reproduces targeting arm32 (as shown above), not aarch64 or any of our x86_64 linux/osx/windows targets.

cc @eddyb, whom we chatted with about this a bit in #servo

[eddyb]

Could someone who already has this set up run cargo rustc --target=arm-unknown-linux-gnueabihf -- -C llvm-args=-print-before-all on the image crate, and gist the output? It would be very helpful.

[larsbergstrom]

The last 10k lines:
https://gist.github.com/anonymous/d0074c0c58021d06062d

[larsbergstrom]

Full file will be available here shortly:
https://dl.dropboxusercontent.com/u/1620890/output.tgz

[larsbergstrom]

7:10 PM <eddyb> larsberg: ugh, isAllocaPromotable is non-trivial and basically depends on all the uses of allocas
7:10 PM  → @brson (opped) joined  
7:11 PM <eddyb> it has to be SROA::rewritePartition, which has its own promotable checks
7:14 PM <eddyb> larsberg: can you get a LLVM debug build?
7:14 PM <eddyb> larsberg: I severely understimated the size of this code
7:14 PM <eddyb> a debugger would let you "call AI->dump()" and at least get to see which alloca it is
7:15 PM  ↔ japaric (was japaric_) nipped out  
7:16 PM <@larsberg> eddyb: Sure, though I might have to do it in a couple of days. I am frantically trying to hack around this so that I can get a one-off ARM32 build of Servo together for a team to do some energy profiling on a board for a paper they're trying to get out in the next few days :-)
7:16 PM <eddyb> :(
7:16 PM <eddyb> larsberg: this is the worst bug

[sanxiyn]

Reduced this. (Originally .bc weighed over 5 MB.) Clone https://github.com/sanxiyn/image/tree/reduce and:

$ cargo rustc --target arm-unknown-linux-gnueabihf -- -O --emit asm -C save-temps
PromoteMemoryToRegister.cpp:531: void {anonymous}::PromoteMem2Reg::run(): Assertion `isAllocaPromotable(AI) && "Cannot promote non-promotable alloca!"' failed.
$ ls -lh target/arm-unknown-linux-gnueabihf/debug/*.bc
298K image.0.no-opt.bc

[larsbergstrom]

@sanxiyn Awesome work - thanks for doing this! It would have taken me a lot longer, and I probably wouldn't have gotten it down so far.

[alexcrichton]

Minimized further: https://gist.github.com/alexcrichton/f7b527d749f1784508b1

Not... sure what to learn from that

[eddyb]

@alexcrichton The challenge is to get clang to trip the same assert, to prove it's a LLVM bug and have it reported upstream.

[MagaTailor]

I understand it's a cross-compilation-only bug as it definitely doesn't reproduce natively.

[eddyb]

@petevine Is there a way to check if it's a 64-bit -> 32-bit issue? That's the first thing that jumps to mind.

[MagaTailor]

Not sure what you meant by that. One more thing, the crates used here seem to be the official armv6 ones, whereas I'm using a natively built armv7 compiler so maybe there's some mixing of armv6/v7 code or tools which could be a no-no for C/C++ parts.

[eddyb]

@petevine I mean, cross-compiling for x86 from x64 or for arm32 from aarch64 - if it's a 32-64-bit issue, they should both trigger it.