We are seeing some behavior we don't understand. Some of our functions are not showing up in the Call Graph because their calls contain bitcasts. The Call Graph then considers them to be external nodes. The calls look as follows: %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] After looking deeper, we noticed that the 'convert' function above did not have a prototype in the actual c source code. After adding a prototype and running llvm-gcc again, the call no longer contained the bitcast and looked like any other normal call. This may be more related to gcc, but we're wondering why the initial call to a function without a prototype contained a bitcast while a function with a prototype does not. We can go into the code and add prototypes and get around the problem, but we'd like to better understand what's going on to see if a better solution exists. Thanks, Ben Mayne -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080507/bda43d7f/attachment.html>
On Wed, 7 May 2008, Ben Mayne wrote:> We are seeing some behavior we don't understand. Some of our functions > are not showing up in the Call Graph because their calls contain > bitcasts. The Call Graph then considers them to be external nodes. > The calls look as follows: > > %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 > (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] > > After looking deeper, we noticed that the 'convert' function above did > not have a prototype in the actual c source code. After adding a > prototype and running llvm-gcc again, the call no longer contained the > bitcast and looked like any other normal call. > > This may be more related to gcc, but we're wondering why the initial > call to a function without a prototype contained a bitcast while a > function with a prototype does not. We can go into the code and add > prototypes and get around the problem, but we'd like to better > understand what's going on to see if a better solution exists.The instcombine pass fixes this. -Chris -- http://nondot.org/sabre/ http://llvm.org/