On 10 January 2012 01:52, Simon Marlow wrote:
> It's great that you're now tracking the liveness of GlobalRegs, but the LLVM
> code here still doesn't look as good. Any idea why? (this bit of code is
> executed a *lot*, saving a few instructions here is worthwhile)
No idea at moment. I was disa
On 10/01/2012 09:15, David Terei wrote:
Hi Simon,
This is finally fixed!
LLVM now creates this code for Updates.cmm:
stg_upd_frame_info: # @stg_upd_frame_info
# BB#0: # %cL
subq $24, %rsp
movq 8(%rbp), %rdx
movq %rbx, 8(%rdx)
Hi Simon,
This is finally fixed!
LLVM now creates this code for Updates.cmm:
stg_upd_frame_info: # @stg_upd_frame_info
# BB#0: # %cL
subq $24, %rsp
movq 8(%rbp), %rdx
movq %rbx, 8(%rdx)
movq $stg_BLACKHOLE_info, (%rdx)
movq
OK, I've created a ticket for this issue here
http://hackage.haskell.org/trac/ghc/ticket/4308
On 13 September 2010 18:29, Simon Marlow wrote:
> On 13/09/2010 09:03, David Terei wrote:
>>
>> Hi Simon,
>>
>> Hmm, I've been trying to find a nasty performance regression when ghc
>> is bootstrapped wi
On 13/09/2010 09:03, David Terei wrote:
Hi Simon,
Hmm, I've been trying to find a nasty performance regression when ghc
is bootstrapped with llvm, this problem must be a large part of this
so thanks.
Right, I expect the mfence on every update is costing quite a lot (one
of those can be hundre
Hi Simon,
Hmm, I've been trying to find a nasty performance regression when ghc
is bootstrapped with llvm, this problem must be a large part of this
so thanks.
On 10 September 2010 19:22, Simon Marlow wrote:
> There are a couple of worrying things here:
>
> - the mfence instruction, which I thi
Hi David (& cvs-ghc list),
I just compiled the update code in the RTS (Updates.cmm) with the LLVM backend,
and the generated code is significantly worse than that generated by the NCG.
There seems to be a lot of unnecessary spilling across a foreign call. Here's
the NCG version:
stg_upd_fram
