<div dir="ltr">That's a nice read, thanks for the pointer. I agree with the solution presented there. If we can do that it will be awesome. If help is needed I can spend some time on it.<div><br></div><div>One of the things that I noticed is that the code can be optimized significantly if we know the common case so that we can optimize that path at the expense of less common path. At times I saw wild difference in performance just by a very small change in the source. I could attribute the difference to code blocks having moved and differently placed jump instructions or change in register allocations impacting the common case more. This could be avoided if we know the common case.</div><div><br></div><div>The common case is not visible or obvious to low level tools. It is easier to write the code in a low level language like C such that it is closer to how it will run on the processor, we can also easily influence gcc from the source level. It is harder to do the same in a high level language like Haskell. Perhaps there is no point in doing so. What we can do instead is to use the llvm toolchain to perform feedback directed optimization and it will adjust the low level code accordingly based on your feedback runs. That will be entirely free since it can be done at the llvm level.</div><div><br></div><div>My point is that it will pay off in things like that if we invest in integrating llvm better.</div><div><br></div><div>-harendra</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 June 2016 at 16:48, Karel Gardas <span dir="ltr"><<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/16/16 12:53 PM, Harendra Kumar wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A thought that came to my mind was whether we should focus on getting<br>
better code out of the llvm backend or the native code generator. LLVM<br>
seems pretty good at the specialized task of code generation and low<br>
level optimization, it is well funded, widely used and has a big<br>
community support. That allows us to leverage that huge effort and take<br>
advantage of the new developments. Does it make sense to outsource the<br>
code generation and low level optimization tasks to llvm and ghc<br>
focussing on higher level optimizations which are harder to do at the<br>
llvm level? What are the downsides of using llvm exclusively in future?<br>
</blockquote>
<br></span>
Good reading IMHO about the topic is here: <a href="https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend</a><br>
<br>
Cheers,<br>
Karel<br>
<br>
</blockquote></div><br></div>