llvm dev - Feb 2013 - [LLVMdev] Question about compilation result - taking address of input array member

Hello,

I'm playing around with some LEA-related code generation on x86-64
(trunk LLVM & Clang), and I run into a case I don't understand:

$ cat takeaddr.c
int* bar(int table[10]) {
  return &table[2];
}

$ clang -cc1 -emit-llvm takeaddr.c
$ cat takeaddr.ll
; ModuleID = 'takeaddr.c'
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-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32* @bar(i32* %table) nounwind {
entry:
  %table.addr = alloca i32*, align 8
  store i32* %table, i32** %table.addr, align 8
  %0 = load i32** %table.addr, align 8
  %arrayidx = getelementptr inbounds i32* %0, i64 2
  ret i32* %arrayidx
}

$ llc -O3 takeaddr.ll -o -
.file "takeaddr.ll"
.text
.globl bar
.align 16, 0x90
.type bar, at function
bar:                                    # @bar
# BB#0:                                 # %entry
movq %rdi, -8(%rsp)
leaq 8(%rdi), %rax
ret
.Ltmp0:
.size bar, .Ltmp0-bar


.section ".note.GNU-stack","", at progbits

The first instruction in "bar" is not clear. Why is it needed? It
seems harmless, but does it serve any purpose? Alignment? ISTM that
the leaq suffices to pefrorm the actual task of the function. Is this
a missed optimization of some sort?

Thanks in advance,
Eli

On Fri, Feb 1, 2013 at 12:11 PM, Eli Bendersky <eliben at google.com>
wrote:
> Hello,
>
> I'm playing around with some LEA-related code generation on x86-64
> (trunk LLVM & Clang), and I run into a case I don't understand:
>
> $ cat takeaddr.c
> int* bar(int table[10]) {
>   return &table[2];
> }
>
> $ clang -cc1 -emit-llvm takeaddr.c
> $ cat takeaddr.ll
> ; ModuleID = 'takeaddr.c'
> 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-S128"
> target triple = "x86_64-unknown-linux-gnu"
>
> define i32* @bar(i32* %table) nounwind {
> entry:
>   %table.addr = alloca i32*, align 8
>   store i32* %table, i32** %table.addr, align 8
>   %0 = load i32** %table.addr, align 8
>   %arrayidx = getelementptr inbounds i32* %0, i64 2
>   ret i32* %arrayidx
> }
>
> $ llc -O3 takeaddr.ll -o -
> .file "takeaddr.ll"
> .text
> .globl bar
> .align 16, 0x90
> .type bar, at function
> bar:                                    # @bar
> # BB#0:                                 # %entry
> movq %rdi, -8(%rsp)
> leaq 8(%rdi), %rax
> ret
> .Ltmp0:
> .size bar, .Ltmp0-bar
>
>
> .section ".note.GNU-stack","", at progbits
>
> The first instruction in "bar" is not clear. Why is it needed? It
> seems harmless, but does it serve any purpose? Alignment? ISTM that
> the leaq suffices to pefrorm the actual task of the function. Is this
> a missed optimization of some sort?
>
I should add that if I manually hack takeaddr.ll to avoid the alloca
and store, instead using %table directly in the GEP, the movq goes
away and only leaq remains.

Eli

Hi Eli,

I'm not sure if this is the answer you're looking for, but the alloca,
store and load can be removed by the mem2reg pass, which isn't run by
codegen prepare in llc. If you invoke clang with -O1 or above it will run
mem2reg, producing IR that contains only the gep, and that produces the
assembly you're looking for:

$ clang -cc1 -emit-llvm -O1 takeaddr.c
$ cat takeaddr.ll

define i32* @bar(i32* %table) nounwind readnone {
entry:
  %arrayidx = getelementptr inbounds i32* %table, i64 2
  ret i32* %arrayidx
}

$ llc takeaddr.ll
$ cat takeaddr.s
<snip>
_bar:                                   ## @bar
## BB#0:                                ## %entry
        leaq    8(%rdi), %rax
        ret

Cheers,
Lang.



On Fri, Feb 1, 2013 at 12:14 PM, Eli Bendersky <eliben at google.com>
wrote:
> On Fri, Feb 1, 2013 at 12:11 PM, Eli Bendersky <eliben at google.com>
wrote:
> > Hello,
> >
> > I'm playing around with some LEA-related code generation on x86-64
> > (trunk LLVM & Clang), and I run into a case I don't
understand:
> >
> > $ cat takeaddr.c
> > int* bar(int table[10]) {
> >   return &table[2];
> > }
> >
> > $ clang -cc1 -emit-llvm takeaddr.c
> > $ cat takeaddr.ll
> > ; ModuleID = 'takeaddr.c'
> > 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-S128"
> > target triple = "x86_64-unknown-linux-gnu"
> >
> > define i32* @bar(i32* %table) nounwind {
> > entry:
> >   %table.addr = alloca i32*, align 8
> >   store i32* %table, i32** %table.addr, align 8
> >   %0 = load i32** %table.addr, align 8
> >   %arrayidx = getelementptr inbounds i32* %0, i64 2
> >   ret i32* %arrayidx
> > }
> >
> > $ llc -O3 takeaddr.ll -o -
> > .file "takeaddr.ll"
> > .text
> > .globl bar
> > .align 16, 0x90
> > .type bar, at function
> > bar:                                    # @bar
> > # BB#0:                                 # %entry
> > movq %rdi, -8(%rsp)
> > leaq 8(%rdi), %rax
> > ret
> > .Ltmp0:
> > .size bar, .Ltmp0-bar
> >
> >
> > .section ".note.GNU-stack","", at progbits
> >
> > The first instruction in "bar" is not clear. Why is it
needed? It
> > seems harmless, but does it serve any purpose? Alignment? ISTM that
> > the leaq suffices to pefrorm the actual task of the function. Is this
> > a missed optimization of some sort?
> >
>
> I should add that if I manually hack takeaddr.ll to avoid the alloca
> and store, instead using %table directly in the GEP, the movq goes
> away and only leaq remains.
>
> Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130213/d7b65eaf/attachment.html>