Niewłaściwa zoptymalizowana wartość insertowa LLVM?

Question

Czy należy unikać używania instrukcji "insertvalue" w połączeniu z ładowaniem i przechowywaniem, kiedy emituję kod LLVM? Zawsze uzyskuję zły, zoptymalizowany kod natywny, gdy go używam. Spójrz na poniższy przykład:

; ModuleID = 'mod' 
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" 
target triple = "x86_64-pc-linux-gnu" 

%A = type { i64, i64, i64, i64, i64, i64, i64, i64 } 

@aa = external global %A* 

define void @func() { 
entry: 
    %a1 = load %A** @aa 
    %a2 = load %A* %a1 
    %a3 = insertvalue %A %a2, i64 3, 3 
    store %A %a3, %A* %a1 
    ret void 
} 

Kiedy uruchamiam "LLC -o - -O3 mod.ll", otrzymuję ten straszny kod:

func:         # @func 
.Ltmp0: 
     .cfi_startproc 
# BB#0:         # %entry 
     movq aa(%rip), %rax 
     movq (%rax), %r8 
     movq 8(%rax), %r9 
     movq 16(%rax), %r10 
     movq 32(%rax), %rdi 
     movq 40(%rax), %rcx 
     movq 48(%rax), %rdx 
     movq 56(%rax), %rsi 
     movq %rsi, 56(%rax) 
     movq %rdx, 48(%rax) 
     movq %rcx, 40(%rax) 
     movq %rdi, 32(%rax) 
     movq %r10, 16(%rax) 
     movq %r9, 8(%rax) 
     movq %r8, (%rax) 
     movq $3, 24(%rax) 
     ret 

Ale co chciałbym zobaczyć, czy to :

func:         # @func 
.Ltmp0: 
     .cfi_startproc 
# BB#0:         # %entry 
     movq aa(%rip), %rax 
     movq $3, 24(%rax) 
     ret 

oczywiście mogę używać getelementptr czy coś, ale czasami łatwiej jest wygenerować insertvalue i extractvalue instrukcjami, a chcę to być zoptymalizowane ...

myślę, że byłoby dość łatwe dla Codegen aby zobaczyć, że takie rzeczy są złe:

 movq 56(%rax), %rsi 
     movq %rsi, 56(%rax) 

Answer 1

pierwsze, trzeba pamiętać, że LLC nie robić żadnych optymalizacji IR poziomie. Tak więc powinieneś uruchomić opt, aby uruchomić zestaw optymalizatorów na poziomie IR.

Jednak opcja nie pomaga w tym. Spodziewam się, że zwykli optymalizatorzy na poziomie podczerwieni w jakiś sposób zignorują te rzeczy w gep.

Proszę zgłoś LLVM PR, wygląda na to, że brakowało optymalizacji!