Re: SHA1.hs woes, was Version control systems
I've fixed this problem by increasing the number of registers used on ia64 to 34. The problem will show up again if anyone finds a way to make GCC use even more registers. -heatsink Sorry, I couldn't find the rest of the preceding message. Someone wrote that they had to turn down cc flags to get SHA1.hs to compile on IA64. Yep. What C compiler was being used, and what were the symptoms? GCC. As I recall the symptoms were that gcc used more than 32 registers and then the mangler balked. The reason is that a registerised ia64 build expects to only use the first 32 registers but does not take any precautions to make sure that this is the case. It just relies on the fact that most code coming out of the ghc backend cannot make use of more than a handful of registers. If gcc does actually use more then the mangler catches this. We tried some flags to make gcc restrict itself to a subset of the registers but could not get it to obey. Duncan _ Talk to your Yahoo! Friends via Windows Live Messenger. Find out how. http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yahoo_082008___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SHA1.hs woes, was Version control systems
On 19/08/2008, at 8:57 PM, Ian Lynagh wrote: On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote: Ian: Did this problem result in Intel CC / GCC register allocator freakouts? Have you got me confused with someone else? I don't think I've ever used Intel CC. Sorry, I couldn't find the rest of the preceding message. Someone wrote that they had to turn down cc flags to get SHA1.hs to compile on IA64. What C compiler was being used, and what were the symptoms? SHA1.hs creates vastly more register pressure than any other code I know of (or could find), but only when -O or -O2 is enabled in GHC. If -O and -prof are enabled then the linear allocator runs out of stack slots (last time I checked). I'm wondering three things: 1) If the C compiler could not compile the C code emitted by GHC then maybe we should file a bug report with the CC people. 2) If the register pressure in SHA1.hs is more due to excessive code unfolding than the actual SHA algorithm, then maybe this should be treated as a bug in the simplifier(?) (sorry, I'm not familiar with the core level stuff) 3) Ticket #1993 says that the linear allocator runs out of stack slots, and the graph coloring allocator stack overflows when trying to compile SHA1.hs with -funfolding-use-threshold20. I'm a bit worried about the stack over-flow part. The graph size is O(n^2) in the number of vreg conflicts, which isn't a problem for most code. However, if register pressure in SHA1.hs is proportional to the unfolding threshold (especially if more than linearly) then you could always blow up the graph allocator by setting the threshold arbitrarily high. In this case maybe the allocator should give a warning when the pressure is high and suggest turning the threshold down. Then we could close this issue and prevent it from being re-opened. Cheers, Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SHA1.hs woes, was Version control systems
On Tue, 2008-08-19 at 23:55 +1000, Ben Lippmeier wrote: On 19/08/2008, at 8:57 PM, Ian Lynagh wrote: On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote: Ian: Did this problem result in Intel CC / GCC register allocator freakouts? Have you got me confused with someone else? I don't think I've ever used Intel CC. Sorry, I couldn't find the rest of the preceding message. Someone wrote that they had to turn down cc flags to get SHA1.hs to compile on IA64. Yep. What C compiler was being used, and what were the symptoms? GCC. As I recall the symptoms were that gcc used more than 32 registers and then the mangler balked. The reason is that a registerised ia64 build expects to only use the first 32 registers but does not take any precautions to make sure that this is the case. It just relies on the fact that most code coming out of the ghc backend cannot make use of more than a handful of registers. If gcc does actually use more then the mangler catches this. We tried some flags to make gcc restrict itself to a subset of the registers but could not get it to obey. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
