CMM-to-ASM: Register allocation wierdness

[Harendra Kumar]

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.

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.

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.

My point is that it will pay off in things like that if we invest in
integrating llvm better.

-harendra

On 16 June 2016 at 16:48, Karel Gardas <karel.gardas at centrum.cz> wrote:

> On 06/16/16 12:53 PM, Harendra Kumar wrote:
>
>> A thought that came to my mind was whether we should focus on getting
>> better code out of the llvm backend or the native code generator. LLVM
>> seems pretty good at the specialized task of code generation and low
>> level optimization, it is well funded, widely used and has a big
>> community support. That allows us to leverage that huge effort and take
>> advantage of the new developments. Does it make sense to outsource the
>> code generation and low level optimization tasks to llvm and ghc
>> focussing on higher level optimizations which are harder to do at the
>> llvm level? What are the downsides of using llvm exclusively in future?
>>
>
> Good reading IMHO about the topic is here:
> https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
>
> Cheers,
> Karel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160616/f657964d/attachment.html>