LLVM insertvalue bad optimized?

Question

Should I avoid using the 'insertvalue' instruction combined with load and store when I emit LLVM code? I always get bad optimized native code when I use it. Look at the following example:

; 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
}

When I run "llc -o - -O3 mod.ll", I get this horrible code:

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

But what I would like to see is this:

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

Of course I can use getelementptr or something, but sometimes it is easier to generate insertvalue and extractvalue instructions, and I want these to be optimized...

I think it would be quite easy for the codegen to see that things like these are bad:

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

Answer 1

First, note that llc does not do any IR-level optimizations. So, you should run opt to run the set of IR-level optimizers.

However, opt does not help in this. I'd expect that standard IR-level optimizers canonicalize the stuff into gep somehow.

Please file a LLVM PR, this looks like a missed optimization!