[LLVMdev] Different signatures or smart casting?

[Bruce Hoult]

Traditional *nix linkers and object file formats do not carry any type
information for functions, only the address of the entry point.

It works because when arguments are passed in registers (as they are for
x86_64), everything is passed as the register size (here 64 bit), no matter
what size you declared it.

It can also work on machines that pass arguments on the stack, because
often there is an alignment requirement on the stack pointer. However, that
is more likely to work between i8/i16/i32 than between those and i64. (it
depends on the machine)

On Sat, Apr 11, 2015 at 9:39 PM, Ksenia Dolgorukova <
der.spiegel.sieht.mich at gmail.com> wrote:

> They both was compiled with clang for 64-bit target. These example
> bitcode files was modified by hand to check if this case will work.
> Actually, this feature was revealed when I compiled 'coremark'
> benchmark with LTO for x68-64 target. I think, different signatures
> was caused by preprocessor directives.
> But I wander how can it work.
>
> 2015-04-10 21:05 GMT+03:00 Nick Lewycky <nicholas at mxc.ca>:
> > Ksenia Dolgorukova wrote:
> >>
> >> Hello!
> >> I linked two bitcode files like described below using LTO and find
> >> they are linked fine instead of making an error.
> >> ----------
> >> 1.bc
> >> ----------
> >> ...
> >> define i32 @main(i32 %argc, i8** %argv) #0 {
> >> entry:
> >> ...
> >> %call = call i32 @_Z1aj(i64 2)
> >> ...
> >> }
> >> declare i32 @_Z1aj(i64) #1
> >> ...
> >>
> >> ----------
> >> 2.bc
> >> ----------
> >> ...
> >> define i32 @_Z1aj(i32 %b) #0 {
> >> entry:
> >> ...
> >> }
> >> ...
> >>
> >> ----------
> >>
> >> In the first file function "_Z1aj" is declared as having i64 argument,
> >> whereas in the second file the function "_Z1aj" is described as having
> >> i32 argument!
> >>
> >> Are function signatures different?
> >
> >
> > They're both 'a(unsigned int)', but perhaps you compiled one of them
> > targeting a 32-bit platform and the other targeting a 64-bit platform?
> What
> > triple is at the top of each .bc file?
> >
> >
> >> How does LLVM cast them?
> >> Could it be a bug?
> >>
> >
>
>
>
> --
> Best regards, Ksenia
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150411/a876c0f6/attachment.html>