[cfe-dev] How to inline a C-function during code generation ?

[David Blaikie]

On Wed, May 27, 2015 at 7:22 AM, Nat! <nat at mulle-kybernetik.com> wrote:

> OK, I found out that llc doesn't do the inlining either. I was scratching
> my head why llc -O2 test.ir refused to inline my code. As it turns out,
> the optimization is done by a different program called "opt".
>

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.


>
> So for anyone else interested (and for myself looking this up in a year or
> so :))
>
>         clang -S -emit-llvm -mllvm -disable-llvm-optzns -o test.ir test.c
>
> produces the unoptimized readable IR file
>
>         opt -O2 -o test.opt.bc test.ir
>
> then creates the optimized binary IR, which then can be assembled into an
> .s file with
>
>         llc  -o test.opt.s test.opt.cb
>
> or disassembled into a readable IR again
>
>         llvm-dis -o test.opt.ir test.opt.cb
>
>
> 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):
>

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.


>
> ---
>
> ;LLVM (http://llvm.org/):
> ;  LLVM version 3.6.1
> ;  DEBUG build with assertions.
> ;  Built May 26 2015 (18:26:41).
> :  Default target: x86_64-apple-darwin14.3.0
> ;  Host CPU: core-avx2
> ;  ModuleID = 'test.opt.bc'
> target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-apple-macosx10.10.0"
>
> @.str = private unnamed_addr constant [4 x i8] c"hit\00", align 1
>
> ; Function Attrs: alwaysinline inlinehint nounwind readnone ssp uwtable
> define internal i8* @inline_call(i8* readnone %p, i64 %aux, i8* nocapture
> readnone %params) #0 {
> entry:
>   %cmp = icmp eq i8* %p, inttoptr (i64 305419896 to i8*)
>   %.p = select i1 %cmp, i8* getelementptr inbounds ([4 x i8]* @.str, i64
> 0, i64 0), i8* %p
>   ret i8* %.p
> }
>
> ; Function Attrs: nounwind ssp uwtable
> define i32 @foo(i8* %p, i64 %aux) #1 {
> entry:
>   %call = tail call i32 bitcast (i8* (i8*, i64, i8*)* @inline_call to i32
> (i8*, i64, i8*)*)(i8* %p, i64 -5999611798422882212, i8* %p) #2
>   ret i32 %call
> }
>
> 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" }
> 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" }
> attributes #2 = { nounwind }
> ---
>
> 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.
>
> Ciao
>    Nat!
> ------------------------------------------------------
> i hurt when i think too much i love roadtrips i hate
> my weight i fear being alone for the rest of my life.
>   -- AOL #3696023
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150527/573b71a9/attachment.html>