Simple program fails to compile depending on target os

Hi *,

in the process of improving the ios experience with ghc, I ran into the following issue:
the produced llvm code[1] compiles for `armv7-apple-darwin`, unless optimization level is 0,
however it fails to compile at all for `armv7-apple-ios`.

I was able to reduce the produced code, while retaining the compilation issue on `armv7-apple-ios`
to the following sample case:

————————————————————— 8< —————————————————————
define ghccc void @"f$def"(i32* noalias nocapture %Base_Arg,
                           i32* noalias nocapture %Sp_Arg,
                           i32* noalias nocapture %Hp_Arg,
                           i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg,
                           i32 %SpLim_Arg,
                           float %F1_Arg, float %F2_Arg, float %F3_Arg, float %F4_Arg,
                           double %D1_Arg, double %D2_Arg) #0
                           align 4 prefix <{ i32, i32 }> <{ i32 1, i32 37 }> {

  %someElem = getelementptr inbounds i32, i32* %Base_Arg, i32 203
  %someValue = load i32, i32* %someElem
  %somePtr = inttoptr i32 %someValue to void (i32*, i32*, i32*, i32, i32, i32, i32, i32, float, float, float, float, double, double)*
  tail call ghccc void %somePtr(i32* %Base_Arg,
                                i32* %Sp_Arg,
                                i32* %Hp_Arg,
                                i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg,
                                i32 %SpLim_Arg,
                                float %F1_Arg, float %F2_Arg, float %F3_Arg, float %F4_Arg,
                                double %D1_Arg, double %D2_Arg) #0
  ret void

attributes #0 = { nounwind }
————————————————————— 8< —————————————————————

$ llc sample.ll -mtriple=armv7-apple-darwin # succeeds for 3.7 and 3.8
$ llc sample.ll -mtriple=armv7-apple-ios # fails for 3.7 and 3.8

Any hints as to why this code only compiles for darwin and not for ios, would be greatly appreciated.



I saw the same thing on a checkout from a few months back, but I then
updated and ToT seems to get it right (well, slightly different
CodeGen because the iOS linker only started supporting tail calls at
5.0 or something so -darwin doesn't use them, but both compiled to
correct code). There's certainly been some churn in this bit of code
recently, so the bug was probably fixed incidentally as part of that.



I also found test/CodeGen/ARM/ghc-tcreturn-lowered.ll, which tests only for thumbv7-eabi,
so, i tried a few more variations:

[x] arm64-apple-ios
[x] arm64-apple-ios7.0.0
[x] arm64-apple-darwin
[x] armv7-apple
[x] thumbv7-apple
[x] thumbv7-apple-darwin
[x] i386-apple-ios
[x] i386-apple-darwin

[f] thumbv7-apple-ios
[f] thumbv7-apple-ios7.0.0
[f] armv7-apple-ios

I’ve also just build a HEAD version (LLVM version 3.9.0svn), and the code in fact *does*
compile with 3.9.0svn.


So, just to be clear, your list was from a slightly older version and
we might not have anything to worry about? Otherwise I'm happy to help



I would however suggest to add -mtriple=armv7-apple-ios and -mtriple=armv7-apple-darwin
to the test in test/CodeGen/ARM/ghc-tcreturn-lowered.ll, so that potential regressions,
as found.

The "-darwin" triple shouldn't really be used. Actually, I'm not sure
why it even exists: it could produce pretty much anything without
anyone inside Apple caring as part of their day job.

I'm happy to add tests, but personally I'd suggest
"thumbv7-apple-ios7.0" and "armv7-apple-ios7.0" as the triples (iOS
7.0 is a reasonable baseline). But I'd also suggest GHC uses
"thumbv7-apple-iosN". It's likely to be more performant than "armv7"
and is certainly a lot more tested (as the Clang default).

That’s the one I stated out to begin with. Currently ghc, uses
armv7-apple-darwin10, which however generates:

     warning: .macosx_version_min should only be used for macosx targets
            .macosx_version_min 10, 0

this triple that produces usable libs though. (thumbv7-apple-darwin10 does
compile, however the produced library fails to work properly, which is likely
a separate ghc bug).

I’ll see that ghc used x86_64-apple-macosx10 for macOS builds then instead
of the current x86_64-apple-darwin10.0.0.

In the interim I don’t see a way around armv7-apple-darwin10 for the armv7
builds, as it crashes llc until 3.9 otherwise. For arm64, we’ll use

Any further suggestions are welcome!