[cfe-dev] questions about expansion of builtins.

[Iain Sandoe]

ping, 
any takers?
thanks
Iain

On 13 Sep 2013, at 20:19, Iain Sandoe 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
> <tmp-x86-diff.txt><fract.c>