[LLVMdev] missed optimizations

[Nuno Lopes]

----- Mensagem encaminhada de MAILER-DAEMON at sapo.pt -----
Ok, thank you all for your explanations!
I'll try to implement those improvements in the coming days.

Thanks,
Nuno

----- Original Message -----
>> Hi,
>>
>> I have two questions about optimizations performed by llvm.
>>
>> Consider these simple functions:
>> int x(int b) { return b?4:6; }
>> int y() { return x(0); }
>>
>> int x2() { return 5; }
>> int y2() { return x2(); }
>>
>> the optimized bitcode (with clang + opt -std-compiler-opts) is:
>> define i32 @y(...) nounwind {
>> entry:
>>  ret i32 6
>> }
>>
>> define i32 @y2(...) nounwind {
>> entry:
>>  %call = call i32 (...)* @x2( )  ; <i32> [#uses=0]
>>  ret i32 5
>> }
>>
>> So why does LLVM optimizes the more difficult case, but leaves behind the
>> function call in the easiest case? :)
>
> Pretty simple: LLVM doesn't know how to eliminate the call.
>
> There are a couple of ways it could be eliminated: DCE or inlining.
> The current DCE infrastructure isn't clever enough to do
> interprocedural analysis, so that doesn't eliminate it.  And the
> inliner immediately gives up on varargs functions, so that doesn't
> eliminate it.  And
>
> That said, clang really should be turning int x2() { return x(0); }
> into "define i32 @x2()" rather than "define i32 @x2(...)"; the
> function isn't varargs, and marking it as such could lead to wrong
> code for exotic calling conventions.
>
>>
>> Second question:
>> int f();
>>
>> int g() {
>>  if (f() == 5)  return 3;
>>  return 4;
>> }
>>
>> int h() {
>>  if (g() == 6) return 2;
>>  return 1;
>> }
>>
>> gives the following optimized bc:
>>
>> define i32 @g(...) nounwind {
>> entry:
>>  %call = call i32 (...)* @f( )  ; <i32> [#uses=1]
>>  %cmp = icmp eq i32 %call, 5  ; <i1> [#uses=1]
>>  %retval = select i1 %cmp, i32 3, i32 4  ; <i32> [#uses=1]
>>  ret i32 %retval
>> }
>>
>> define i32 @h(...) nounwind {
>> entry:
>>  %call = call i32 (...)* @g( )  ; <i32> [#uses=1]
>>  %cmp = icmp eq i32 %call, 6  ; <i1> [#uses=1]
>>  %retval = select i1 %cmp, i32 2, i32 1  ; <i32> [#uses=1]
>>  ret i32 %retval
>> }
>>
>> In function h(), llvm doesn't realize that g() never returns 6, and thus
>> it
>> could reduce that function to { g(); return 1; }. Doesn't llvm produce
>> some
>> sort of summary for functions with e.g. their possible return values? If
>> not, is there any pass where I could implement this?  (I have some code
>> that
>> has many opportunities for this kind of optimization)
>
> No, there isn't any such infrastructure at the moment.  The LLVM pass
> that might do that sort of thing is predsimplify, but it isn't an
> interprocedural pass.  It's not necessarily difficult to implement,
> depending on how precise you want it to be, but nobody's implemented
> it; as far as I know, it doesn't provide significant benefits for
> normal C/C++ code.  If there's some specific pattern in your code, you
> could probably throw together a specialized pass pretty quickly.
>
>> Also, shouldn't the function g() get inlined in the h() function? It is
>> inlined only if I change the g() function to be static. So isn't llvm
>> being
>> too conservative when inlining global functions?
>
> The inliner doesn't like varargs; see above.
>
> -Eli



----- Finalizar mensagem encaminhada -----