Защо `-O3` alloca на clang е 2 пъти по-бърз от g++

Относно използването и злоупотребата с alloca

Имам някои показатели в долната част на предишен въпрос. clang очевидно има по-добра реализация в профила на оптимизатора -O3. Какво дава? Клангът пресича ли някакви ъгли? Освен това, тъй като clang е модерен компилатор, има ли някакви предпазни мерки или други интересни свойства в неговата реализация на alloca?


clang memory-management compiler-construction micro-optimization
person Hassan Syed    schedule 28.04.2011    source източник
comment
Това е само странно предположение, но: Ако clang картографира alloca към инструкцията LLVM alloca, пропускът (широко използван, тъй като се грижи за създаването на добре оформен SSA) Reg2Mem може да го трансформира в използване на регистри на ниво LLVM, които получават всички оптимизации, които LLVM предоставя за нормални променливи.   -  person    schedule 28.04.2011

Отговори (1)


arrow_upward
4
arrow_downward

Предположението на delnan е вярно. Но той не отчете, че тестът е много лош и clang може да оптимизира действителната alloca операция от alloca_test.

alloca_test имат само llvm ir операция alloca, но не и alloca() извикване на функция:

%11 = call i32 @_Z18random_string_sizev()
%12 = alloca i8, i32 %11

Сравнете с malloc_test:

%11 = call i32 @_Z18random_string_sizev()
%12 = call i8* @malloc(i32 %11)

Дори с -O1 няма повече alloca в alloca_test:

define void @_Z11alloca_testv() nounwind {
; <label>:0
  %1 = tail call i32 @_Z18random_vector_sizev()
  %2 = icmp sgt i32 %1, 0
  br i1 %2, label %.lr.ph, label %._crit_edge

.lr.ph:                                           ; preds = %.lr.ph, %0
  %i.01 = phi i32 [ %4, %.lr.ph ], [ 0, %0 ]
  %3 = tail call i32 @_Z18random_string_sizev()
  %4 = add nsw i32 %i.01, 1
  %exitcond = icmp eq i32 %4, %1
  br i1 %exitcond, label %._crit_edge, label %.lr.ph

._crit_edge:                                      ; preds = %.lr.ph, %0
  ret void
}

А за malloc_test извикването на malloc все още е тук:

%6 = tail call i32 @_Z18random_string_sizev()
%7 = tail call i8* @malloc(i32 %6)

Трябва също да кажа, че g++ -O3 (тестван 4.1 и 4.5.2) не оптимизира промяната на размера на стека (основен ефект на alloca).

person osgx    schedule 28.04.2011
comment
добре, семантично ефектът е същият, не? Вграждане на семантиката на alloca срещу използване на llvm il повикване, паметта все още се създава в стекова рамка? - person Hassan Syed; 28.04.2011
comment
Не знам дали llvm позволява извикване на alloca (как извиканата функция може да промени размера на стека на повикващия), но alloca ir op е в основния набор от ir операции. llvm.org/docs/LangRef.html#i_alloca - person osgx; 28.04.2011