[LLVMdev] strange code behavior when non-prototyped user function are called

[Chuck Zhao]

  Duncan,

Thank you for the reply.

I fully agree with your explanation on how LLVM-GCC deals with 
user-defined function calls when their respective prototypes are not 
specified.

I guess it is an internal hack on LLVM-IR when such cases happen, and 
-instcombine will naturally clean them up.

I think a better option is just use -O2 (or -std-compile-opts), which 
includes -instcombine as part of its defaults.

As how -instcombine does its work, I will have to read its source code. 
It is currently a task on my todo list for the weekend. :-)


Thank you

Chuck


On 9/30/2010 5:08 AM, Duncan Sands wrote:
> Hi Chuck,
>
>> However, if I comment out the first 2 lines (the prototype declarations),
>> llvm-gcc will generate the following code for foo() instead:
>> define void @foo() nounwind {
>> entry:
>> %0 = call i32 (...)* bitcast (void ()* @bar to i32 (...)*)() nounwind ;<i32>
>> [#uses=0]
> in C a prototype like this
>     void bar()
> or no prototype at all means that bar takes a variable number of arguments
> (corresponds to ... in the LLVM type); if there is no prototype then bar
> is also considered to return i32.
>
> So in foo, the call to bar is technically a call to a function of type i32
> (...).  However later the body of bar is output, at which point the type of
> @bar is corrected to void (void).  This results in a bitcast in the call.
> The instcombine pass should clean this up.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev