| Note that removing the flag isn't a "solution" to the underlying problem | of the intermediate code being awful. Switching to the linear allocator | just permits compilation of core code that was worse than before. Now it | needs to spill more registers when compiling the same source code.
In what way is the intermediate code awful? How could it be fixed? Worth opening a ticket for that issue? At the moment it's invisible because the issue appears superficially to be about register allocation. Simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]] On Behalf Of Ben | Lippmeier | Sent: 05 January 2014 10:47 | To: Kazu Yamamoto (山本和彦) | Cc: [email protected] | Subject: Re: panic when compiling SHA | | | On 04/01/2014, at 23:22 , Kazu Yamamoto (山本和彦) <[email protected]> | wrote: | | > Hi, | > | >>> There are only a fixed number of register spill slots, and when | >>> they're all used the compiler can't dynamically allocate more of | >>> them. | >> | >> Not true any more in 7.8+ with the linear allocator. I think it | >> might still be true for the graph allocator, which is sadly suffering | >> from a little bitrot and probably doesn't generate very good code | >> with the new code generator. | >> | >> So, avoiding -fregs-graph should work around this with 7.8. | > | > I confirmed that removing -fregs-graph should work around this with | > 7.8. | | Ok, my mistake. We originally added -fregs-graph when compiling that | module because both allocators had a fixed stack size, but the graph | allocator did a better job of allocation and avoided overflowing the | stack. | | Note that removing the flag isn't a "solution" to the underlying problem | of the intermediate code being awful. Switching to the linear allocator | just permits compilation of core code that was worse than before. Now it | needs to spill more registers when compiling the same source code. | | Ben. | | _______________________________________________ | ghc-devs mailing list | [email protected] | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
