[LLVMdev] Cross-module function inlining

Nick Lewycky nicholas at mxc.ca
Thu Jan 14 09:03:42 PST 2010

Mark Muir wrote:
> On 14 Jan 2010, at 05:20, Nick Lewycky wrote:
>>> calls to _malloc and _free
>>> weren't being inlined (see example below). I'm not sure why (happens
>>> with or without -simplify-libcalls). So, the resulting .bc file from
>>> 'opt' contains live references to symbols that were in its input .bc,
>>> but for some reason it stripped them.
>> Okay. Could you post an .ll (run 'llvm-dis<  foo.bc') example of where this happens? Just the input and opt commands to run is fine. It's very frustrating to look at C and assembly when the problem is in the IR ->  IR transform itself.
> I've attached the relevant IR (stripped down to the bare minimum). The following commands will reproduce the problem (using vanilla 2.6 versions of the LLVM tools):
> 	llvm-as test_malloc.ll -o - | opt -std-link-opts -o - | llvm-dis -o -
> That strips everything except for @main. The stripping of the two global variables is fine, and there are no references to them left in the IR. But there are live references to @malloc and @free.
> The minimum options required for this behaviour are:
> 	llvm-as test_malloc.ll -o - | opt -internalize -globaldce -o - | llvm-dis -o -
> If I use -disable-internalize with -std-link-opts, then global dead code elimination doesn't remove anything, but inlining still takes place. So that is the solution I'm using at the moment. But I'd like to know why this behaviour is happening, and it would be nice to have global DCE so that the resulting machine assembly is easier to work with (for manual debugging on this architecture).
> Thanks for looking at this.

Thanks, I think it's now pretty clear what's going on. The .ll you 
posted has a @free function with no calls to it. Since it's never 
called, it can be deleted after -internalize.

What happened to your free() calls in the C code is that they turned 
into free instructions in LLVM. You can fix that by passing 
-ffreestanding, but realize that this may trigger other missed 
optimizations as clang/gcc will cease assuming that functions with 
certain names do certain things.


More information about the llvm-dev mailing list