Displaying 3 results from an estimated 3 matches for "pefrorm".
2013 Feb 01
2
[LLVMdev] Question about compilation result - taking address of input array member
...%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
2013 Feb 01
0
[LLVMdev] Question about compilation result - taking address of input array member
...; .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
2013 Feb 14
1
[LLVMdev] Question about compilation result - taking address of input array member
...r
> >
> >
> > .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
>...