<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 7:22 AM, Nat! <span dir="ltr"><<a href="mailto:nat@mulle-kybernetik.com" target="_blank">nat@mulle-kybernetik.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK, I found out that llc doesn't do the inlining either. I was scratching my head why llc -O2 <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__test.ir&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=rFZQgeoU7XU7a3mPjmD2fBEpuEJezQwb_9njAbHgx78&s=Er63fJow2mieXKGI8inwZWCHpvlTHIGxQ9yMM4cqQS8&e=" target="_blank">test.ir</a> refused to inline my code. As it turns out, the optimization is done by a different program called "opt".<br></blockquote><div><br>Well, yes and no. These utilities are wrappers around specific libraries, but clang actually calls into all those libraries directly too - the separate utilities are just conveniences for developers of Clang/LLVM, etc. But, yes, clang + opt + llc is one way to break things down for testing. But remember, as I said previously, the specific optimization pipeline used by Clang isn't necessarily teh same one used by opt, etc. So if you want to test what's actually running, I'd suggest you test with Clang directly.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So for anyone else interested (and for myself looking this up in a year or so :))<br>
<br>
        clang -S -emit-llvm -mllvm -disable-llvm-optzns -o <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__test.ir&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=rFZQgeoU7XU7a3mPjmD2fBEpuEJezQwb_9njAbHgx78&s=Er63fJow2mieXKGI8inwZWCHpvlTHIGxQ9yMM4cqQS8&e=" target="_blank">test.ir</a> test.c<br>
<br>
produces the unoptimized readable IR file<br>
<br>
        opt -O2 -o test.opt.bc <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__test.ir&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=rFZQgeoU7XU7a3mPjmD2fBEpuEJezQwb_9njAbHgx78&s=Er63fJow2mieXKGI8inwZWCHpvlTHIGxQ9yMM4cqQS8&e=" target="_blank">test.ir</a><br>
<br>
then creates the optimized binary IR, which then can be assembled into an .s file with<br>
<br>
        llc  -o test.opt.s test.opt.cb<br>
<br>
or disassembled into a readable IR again<br>
<br>
        llvm-dis -o <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__test.opt.ir&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=rFZQgeoU7XU7a3mPjmD2fBEpuEJezQwb_9njAbHgx78&s=IQCyIkIcKL4P5nKggxjpBxGY60N7fGMhT2Fg6xEbScE&e=" target="_blank">test.opt.ir</a> test.opt.cb<br>
<br>
<br>
I am getting closer to the reason, why my code does not get inlined, but I am not there yet. I can put the following through opt -O2  and it does not inline (though "inline_call " is even  marked as alwaysinline):<br></blockquote><div><br>I don't know the specific reason, but you could break into a debugger in opt when the AlwaysInline pass is running and see walk through it to see why it's failing to inline.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
---<br>
<br>
;LLVM (<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=rFZQgeoU7XU7a3mPjmD2fBEpuEJezQwb_9njAbHgx78&s=MEqdTzlatS-HnBh7H_AzfKah3FVbtr8A80tQP3k5hQY&e=" target="_blank">http://llvm.org/</a>):<br>
;  LLVM version 3.6.1<br>
;  DEBUG build with assertions.<br>
;  Built May 26 2015 (18:26:41).<br>
:  Default target: x86_64-apple-darwin14.3.0<br>
;  Host CPU: core-avx2<br>
;  ModuleID = 'test.opt.bc'<br>
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"<br>
target triple = "x86_64-apple-macosx10.10.0"<br>
<br>
@.str = private unnamed_addr constant [4 x i8] c"hit\00", align 1<br>
<br>
; Function Attrs: alwaysinline inlinehint nounwind readnone ssp uwtable<br>
define internal i8* @inline_call(i8* readnone %p, i64 %aux, i8* nocapture readnone %params) #0 {<br>
entry:<br>
  %cmp = icmp eq i8* %p, inttoptr (i64 305419896 to i8*)<br>
  %.p = select i1 %cmp, i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), i8* %p<br>
  ret i8* %.p<br>
}<br>
<br>
; Function Attrs: nounwind ssp uwtable<br>
define i32 @foo(i8* %p, i64 %aux) #1 {<br>
entry:<br>
  %call = tail call i32 bitcast (i8* (i8*, i64, i8*)* @inline_call to i32 (i8*, i64, i8*)*)(i8* %p, i64 -5999611798422882212, i8* %p) #2<br>
  ret i32 %call<br>
}<br>
<br>
attributes #0 = { alwaysinline inlinehint nounwind readnone ssp uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }<br>
attributes #1 = { nounwind ssp uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }<br>
attributes #2 = { nounwind }<br>
---<br>
<br>
I suspect it has something to do with the "call bitcast". But to me it appears to be more like a limitation of llvm not to inline it, then a coding error of mine.<br>
<br>
Ciao<br>
<span class="HOEnZb"><font color="#888888">   Nat!<br>
------------------------------------------------------<br>
i hurt when i think too much i love roadtrips i hate<br>
my weight i fear being alone for the rest of my life.<br>
  -- AOL #3696023<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>