[cfe-dev] questions about expansion of builtins.

[Eric Christopher]

I'd probably expect to lower builtins to multiple basic blocks in the
backend if they needed to do so...

-eric

On Fri, Sep 13, 2013 at 12:19 PM, Iain Sandoe <iain at codesourcery.com> wrote:
> Hello folks,
>
> I am working on an out-of-tree port that would, for some cases, like to expand builtins to multiple BBs.
>
> So far, I've not succeeded in finding any guidance other than the code in CGBuiltin.cpp, Builtin.def, SemaChecking.cpp etc. (specifically, there doesn't appear to be anything in the internals doc.)
>
> For simple builtins that, effectively, just pass the buck to LLVM for expansion at lower-to-asm time everything works fine.  The problems start when they generate BBs as part of the expansion.
>
> ----
>
> To try and understand things better, I made a simplistic example "__factorial()" built-in that should be applicable to any port.
>
> The code for this is attached, along with a driver program; this is set up for X86 so that folks can explore it for themselves [perhaps also this might form the basis of a documentation example, if appropriate].  The CG follows, I hope, the advice of the FE tutorial, although - of course - it could be missing some vital point …
>
> ----
>
> OK, so having established that the example is trivial and only intended for illustration; nevertheless, it does exhibit the same issues I see with my real-world builtins.
>
> Note also that, while one could just as well replace the trivial example here with an inlined function, that is not true of the 'real-world' built-ins I'm trying to expand (part of the job is to overload the CG for different operand types).
>
> ----
>
> What I find is that for -O0/O1 the CG behaves as expected - producing (at O1) what looks like correct (and is functional) IR to me:
>
> ; Function Attrs: noinline nounwind readnone ssp uwtable
> define i32 @foo(i32 %x) #0 {
> entry:
>   %nothing.to.do = icmp ult i32 %x, 2
>   %init.res = select i1 %nothing.to.do, i32 1, i32 %x
>   br i1 %nothing.to.do, label %finished, label %fact_loop
>
> fact_loop:                                        ; preds = %entry, %fact_loop
>   %arg.0 = phi i32 [ %fact.prod, %fact_loop ], [ %init.res, %entry ]
>   %tmp.0 = phi i32 [ %tmp.dec, %fact_loop ], [ %x, %entry ]
>   %tmp.dec = add i32 %tmp.0, -1
>   %fact.prod = mul i32 %tmp.dec, %arg.0
>   %done = icmp ult i32 %tmp.dec, 2
>   br i1 %done, label %finished, label %fact_loop
>
> finished:                                         ; preds = %fact_loop, %entry
>   %arg.1 = phi i32 [ %init.res, %entry ], [ %fact.prod, %fact_loop ]
>   ret i32 %arg.1
> }
>
> ==== problems:
>
> (1) If I try to compile with debug enabled (regardless of optimisation level) I get:
>
> $ ./Debug+Asserts/bin/clang ../fract.c -g -emit-llvm -S
> Assertion failed: (unsigned(ScopeIdx) <= Ctx.pImpl->ScopeRecords.size() && "Invalid ScopeIdx!"), function getScopeAndInlinedAt, file /Volumes/sc2_src/llvm-trunk/lib/IR/DebugLoc.cpp, line 60.
> 0  clang             0x00000001031b721b llvm::sys::PrintStackTrace(__sFILE*) + 38
>
> (2) If I try to compile -O2, then I get:
>
> $ ./Debug+Asserts/bin/clang ../fract.c -O2 -emit-llvm -S
> Assertion failed: (LHS->getType() == RHS->getType() && "Equality but unequal types!"), function propagateEquality, file /Volumes/sc2_src/llvm-trunk/lib/Transforms/Scalar/GVN.cpp, line 2045.
> 0  clang             0x000000010bac521b llvm::sys::PrintStackTrace(__sFILE*) + 38
>
> Neither case is proving tractable to analysis (at least by me) mainly, because I'm not sure what the "correct" scenario should be.
>
> ===== Initial questions:
>
> (of course, any pointers to mistakes in my coding assumptions equally welcome).
>
> 1. Is it reasonable to expect to be able to expand a built-in in this manner?
>
> 2. Is there some decoration (for debug at least) needed to label the expansion as belonging to the function that has, effectively, become inlined?
>
> 3. Any hints about where to start with the O2 problem would be appreciated - although there seems little point in persuing that until 1 and 2 are resolved.
>
> Thanks,
> Iain
>
> The patch applies to TOT as of 2 hrs ago.
> if one does "clang fract.c -O1 -o fract " [-O0 or -O1] then it should produce a working code - at least on x86.
>
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>