<div><div style="font-family: "lucida Grande", Verdana;">Hi John.</div><div style="font-family: "lucida Grande", Verdana;">Thanks for the info. Currently I'm marking fooo() by hand by adding the always_inline attribute then run the always inline pass using the following code:</div><div style="font-family: "lucida Grande", Verdana;"><br></div><div style="font-family: "lucida Grande", Verdana;">```</div><div style="font-family: "lucida Grande", Verdana;"><div>AnalysisManager<Module> AM;</div><div>AlwaysInlinerPass* InlinerPass=cast<AlwaysInlinerPass>(createAlwaysInlinerLegacyPass());</div><div>InlinerPass->run(M,AM);</div><div>delete InlinerPass;</div></div><div style="font-family: "lucida Grande", Verdana;">```</div><div style="font-family: "lucida Grande", Verdana;">However the CallSites are not inlined. </div><div style="font-family: "lucida Grande", Verdana;">Reading lib/Transforms/IPO/AlwaysInliner.cpp , it says ``<span style="caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46);"> </span><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">if</span><span style="caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46);"> (CS.</span><span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">getCalledFunction</span><span style="caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46);">() == &F)</span>`` , since after linking the CallSites become indirect calls with Bitcast ConstantExpr as target I think that's why the inliner has no effect.</div><div style="font-family: "lucida Grande", Verdana;">Any hints?</div></div><div><includetail><div> </div><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "John McCall"<rjmccall@apple.com>;</div><div><b>Date: </b> Tue, Jul 3, 2018 12:23 PM</div><div><b>To: </b> "Zhang"<admin@mayuyu.io>; <wbr></div><div><b>Cc: </b> "cfe-dev"<cfe-dev@lists.llvm.org>; "llvm-dev"<llvm-dev@lists.llvm.org>; <wbr></div><div><b>Subject: </b> Re: [cfe-dev] Why Clang is yielding different LLVM IR return type forthe same function</div></div><div> </div><div style="position:relative;">> On Jul 2, 2018, at 11:48 PM, Zhang via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br>> Hi:<br>> So I have a library function called fooo() in a source file B.c and an external A.c file that is referencing a function fooo() in it.<br>> foo is returning a pointer to a structure<br>> <br>> A.ll:<br>> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*, %struct.doo*)* }<br>> declare i8* @fooo() #2<br>> <br>> B.ll:<br>> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*, %struct.doo*)* }<br>> define noalias %struct._bar* @fooo() #2{<br>>    ..........<br>> }<br>> <br>> <br>> I am implementing a transform pass that operates on the merged version of A.ll and B.ll , since they have different implementations llvm-link is inserting extra bitcasts and thus various passes failed to operate, for example the Inliner pass.<br>> Is there anything else I could do to achieve what I need? Cheers<br><br>I wouldn't expect a bitcast to block inlining.  It's hard to say why Clang is generating different code here.<br><br>John.<br></div></div><!--<![endif]--></includetail></div>