<div dir="ltr"><div><div><div>Hi,<br><br>It doesn't seem the same to me.<br><br>Unlike the bug you point to, the C-- does not have any extra stores. The stores and loads appear first in the LLVM. I am attaching the C--, LLVM and assembly codes for the function.<br>
</div><br></div>The real missed opportunity seems to me the absence of a recognition that we are in fact making a tail call to ourselves. Recognizing that might allow jumping to some point after the initial stores.<br><br>
</div>Jyotirmoy Bhattacharya<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 30, 2014 at 4:14 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jyotirmoy,<br>
<br>
I didn't read your assembly carefully, but it sounds similar to<br>
<a href="https://ghc.haskell.org/trac/ghc/ticket/8905" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8905</a>, which is not fixed yet.<br>
<br>
On Wed, Jul 30, 2014 at 12:03 PM, Jyotirmoy Bhattacharya<br>
<div><div class="h5"><<a href="mailto:jyotirmoy@jyotirmoy.net">jyotirmoy@jyotirmoy.net</a>> wrote:<br>
> On reading this again I realise that I got the order of loads and stores<br>
> wrong. The arguments are being stored on entering the function and loaded<br>
> before the call. But still, is there a chance of eliminating this<br>
> redundancy?<br>
><br>
> Jyotirmoy<br>
><br>
><br>
> On Wed, Jul 30, 2014 at 1:54 PM, Jyotirmoy Bhattacharya<br>
> <<a href="mailto:jyotirmoy@jyotirmoy.net">jyotirmoy@jyotirmoy.net</a>> wrote:<br>
>><br>
>> Dear All,<br>
>><br>
>> I am new to Haskell so please forgive me if I am asking about something<br>
>> already well-understood.<br>
>><br>
>> I was trying to understand the performance of my Haskell program compiled<br>
>> with the LLVM backend. I used -ddump-llvm to dump the LLVM assembly and then<br>
>> ran llc -O3 on the resulting file to look at the native assembly.<br>
>><br>
>> One of the generated function starts off with<br>
>> s5BH_info: # @s5BH_info<br>
>> # BB#0:<br>
>> subq $208, %rsp<br>
>> movq %r13, 200(%rsp)<br>
>> movq %rbp, 192(%rsp)<br>
>> movq %r12, 184(%rsp)<br>
>> movq %rbx, 176(%rsp)<br>
>> movq %r14, 168(%rsp)<br>
>> movq %rsi, 160(%rsp)<br>
>> movq %rdi, 152(%rsp)<br>
>> movq %r8, 144(%rsp)<br>
>> movq %r9, 136(%rsp)<br>
>> movq %r15, 128(%rsp)<br>
>> movss %xmm1, 124(%rsp)<br>
>> movss %xmm2, 120(%rsp)<br>
>> movss %xmm3, 116(%rsp)<br>
>> movss %xmm4, 112(%rsp)<br>
>> movsd %xmm5, 104(%rsp)<br>
>> movsd %xmm6, 96(%rsp)<br>
>><br>
>> At some point down the line the function makes a tail call to itself and<br>
>> this is the code generated<br>
>> movq %r14, 168(%rsp)<br>
>> movq 200(%rsp), %r13<br>
>> movq 192(%rsp), %rbp<br>
>> movq 184(%rsp), %r12<br>
>> movq 176(%rsp), %rbx<br>
>> movq 128(%rsp), %r15<br>
>> movsd 104(%rsp), %xmm5<br>
>> addq $208, %rsp<br>
>> jmp s5BH_info<br>
>><br>
>> So it looks like some values are being moved from registers to the stack<br>
>> only to be immediately moved from the stack to the register on entry to the<br>
>> function. It should be possible to eliminate both the load and the stores.<br>
>><br>
>> Is this behaviour due to LLVM or GHC? If it is GHC, it this an<br>
>> optimization a newcomer can attempt to implement or are there deep issues<br>
>> here?<br>
>><br>
>> Jyotirmoy Bhattacharya<br>
>><br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
</blockquote></div><br></div>