search for: extfunc

...t.cpp:302! This is probably in the SPU backend, as all (most) other backends compile the example just fine? Where do I start to look if I want to fix this? I can file a PR if this is not in the SPU backend. kalle P.s. This is a simplification of programs that crash: declare [8 x [8 x float]]* @extFunc() define void @testFunc() { %sl8_5 = tail call [8 x [8 x float]]* @extFunc() br label %Entry Entry: %idx = phi i64 [ 0, %0 ], [ %next, %Entry ] %scevgep = getelementptr [8 x [8 x float]]* %sl8_5, i64 0, i64 %idx, i64 0 %next = add i64 %idx, 1 %exitco...

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

...executed > at /home/kraiskil/llvm/svn-clean/llvm/lib/CodeGen/RegAllocFast.cpp:302! This is RegAllocFast's way of saying "Oops, I clobbered the return value from your CALL. Didn't think you would need it." The problem is this code: BB#0: derived from LLVM BB %0 BRASL <ga:@extFunc>, %R0<imp-def>, %R1<imp-def>, %R3<imp-def>, %R0<imp-use>, ... %reg1028<def> = ILv4i32 0 %reg1027<def> = ORi64_v2i64 %reg1028 ADJCALLSTACKUP 0, %R1<imp-def>, %R1<imp-use> %reg1029<def> = LRr32 %R3 The return value from the call is in %R3,...

...if you need example code. > Thanks for the tip. This got fixed in 105601. And with that, half of the problematic tests appearing with --regalloc=fast flag started working. Unfortunately the second half started to miscompile :( Also, I now see some rather unoptimal code, e.g: ... brasl $lr, extFunc lr $3, $3 lr $3, $3 ... ('lr rt, ra' moves ra->rt). I guess the miscompilations are due to the same problem as this sort of stuff gets generated. I'm looking into it, but do you have any more of those useful tips? ;) The code I used is the same test case as earlier in this chain....