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

[mats petersson]

Looks like you are calling a function with no prototype or with the wrong
prototype - which is why it's being bitcast.

32 (i8*, i64, i8*)* is
int (*)(void *, int64_t, char *)

[or void * instead of char * - impossible to tell apart in LLVM IR, but I'm
guessing based on str in your inline function] in C.

And your function is declared as
i8* (i8*, i64, i8*)*
so
char* (*)(char *, int64_t, char *)

Do you actually want to return an i32 as a pointer?

Maybe you shoudl declare foo to return a pointer to char (or void).

On 27 May 2015 at 15:22, 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".
>
> 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):
>
> ---
>
> ;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/e5e6aae4/attachment.html>