llvm dev - Dec 2017 - Some strange i64 behavior with arm 32bit. (Raspberry Pi)

Hi,

I have this function:
```
define private ghccc void @c4JC_info(i32*, i32*, i32*, i32, i32, i32, i32, i32)
prefix { i32, i32, i32 } { i32 add (i32 sub (i32 ptrtoint ({ i32, i32, i32, i32,
i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32
}* @S4J7_srt to i32), i32 ptrtoint (void (i32*, i32*, i32*, i32, i32, i32, i32,
i32)* @c4JC_info to i32)), i32 16), i32 0, i32 196638 } {
  %9 = add i32 %3, 3
  %10 = inttoptr i32 %9 to i64*
  %11 = load i64, i64* %10, align 8
  call void @debug(i64 -1)
  call void @debug(i64 1)
  call void @debug(i64 4294967296)
  call void @debug(i64 4294967297)
  call void @debug(i64 4294967298)
  [...]

  ret void
}
```
where @debug is:
```
@.str = private unnamed_addr constant [6 x i8] c"%lld\0A\00", align 1
declare i32 @printf(i8*, ...)

define void @debug(i64 %val) {
  %cret = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([6 x i8], [6 x
i8]* @.str, i32 0, i32 0), i64 %val)
  ret void
}
```


When I run it the output is:
```
-1
4294967296 ; expected this to be          1 = [0x0,0x0,0x0,0x0
           ;                                  ,0x0,0x0,0x0,0x1]
1          ; expected this to be 4294967296 = [0x0,0x0,0x0,0x1
           ;                                  ,0x0,0x0,0x0,0x0]
4294967297 ; this is correct due to symmetry
8589934593 ; expected this to be 4294967298 = [0x0,0x0,0x0,0x1
           ;                                  ,0x0,0x0,0x0,0x2]
```

As such it looks like my words are in reverse somehow.


However, if I try to build something similar and boil it down to just a simple C
main function:
```
define i32 @main(i32, i8**) {
  call void @debug(i64 -1)
  call void @debug(i64 1)
  call void @debug(i64 4294967296)
  call void @debug(i64 4294967297)
  call void @debug(i64 4294967298)
  ret i32 0

}
```
it produces the correct result
```
-1
1
4294967296
4294967297
4294967298
```

If someone could offer some hint, where to look further for debugging this,
I'd very much appreciate the advice!
I'm a bit lost right now how to figure out why I end up getting swapped
words.

Thank you in advance!

Cheers,
 Moritz

Hi Moritz,
> If someone could offer some hint, where to look further for debugging this,
I'd very much appreciate the advice!
> I'm a bit lost right now how to figure out why I end up getting swapped
words.
If one file was compiled for big-endian ARM and the other for
little-endian that could be the result. I'm not aware of any other
possible cause and from local tests I don't think the "ghccc"
alone
explains the difference.

So maybe some glitch in how GHC was configured on your system? What's
the triple at the top of the GHC module and the module containing the
definition of @debug?

Cheers.

Tim.

Hi Tim,
thanks for the swift response!

@debug is defined in the same module, which makes this all the more confusing.


The target information from the working example are:
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "armv6kz--linux-gnueabihf"


from the ghc produced module:
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "arm-unknown-linux-gnueabihf"

However there ones more thing, I could think of, arm does allow mixed mode
I believe. And as such as the code from the ghc produced module is called
from outside of the module, could the endianness be set there prior to
entering the function?

The working module contains the main directly and is not called from a main
function in a different module.

I've also tried to define a regular c function with the same code and called
that from within the ghccc function with the same (incorrect) results.

Any further ideas I could expore?


Cheers,
 Moritz
> On Dec 1, 2017, at 4:26 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> Hi Moritz,
>> If someone could offer some hint, where to look further for debugging
this, I'd very much appreciate the advice!
>> I'm a bit lost right now how to figure out why I end up getting
swapped words.
> 
> If one file was compiled for big-endian ARM and the other for
> little-endian that could be the result. I'm not aware of any other
> possible cause and from local tests I don't think the "ghccc"
alone
> explains the difference.
> 
> So maybe some glitch in how GHC was configured on your system? What's
> the triple at the top of the GHC module and the module containing the
> definition of @debug?
> 
> Cheers.
> 
> Tim.