[GHC] #701: Better CSE optimisation
#701: Better CSE optimisation
-+--
Reporter: simonmar |Owner:
Type: task | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.4.1
Severity: normal| Keywords:
Os: Unknown | Difficulty: Difficult (1 week)
Architecture: Unknown |
-+--
GHC's CSE optimisation is pretty weedy. It looks for expressions like
this:
{{{
let x = e1 in e2
}}}
and replaces all occurrences of e1 in e2 with x. This doesn't do full
CSE, but it does catch some cases. There have been case where full CSE
would be significantly beneficial, though.
One possible way forward is to have a separate CSE pass that transformed
expressions containing common subexpressions into the let-form above, and
let the existing CSE pass do the final replacement.
We must be cautious, though: increasing sharing can introduce space leaks.
Sometimes we can prove that this cannot happen, for example when the
shared object is primitive, or has a bounded size.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/701
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci command history broken under rxvt and xterm
Bruno MartÃnez wrote: When using ghci with rxvt under cygwin, the command history doesn't work. When I press the up arrow, for example, the cursor moves up, instead of showing the previous command. xterm has the same problem, but with cygwin's default console it works. I don't know where to start looking. Maybe this is something solveable thinkering with ~/.inputrc, but I'm not knowledgeable enough about it. GHCi doesn't use readline on Windows, at least by default, so nothing is interpreting the up or down arrow keys so they generate some control sequences that just move the cursor around. Something strange is afoot though, because you say that it works under a cygwin console - that's not the case here. What version of GHC is this? where did you get it? I believe that GHC can be compiled against mingw's readline library, but I seem to recall it was pretty flaky which is why we don't do it. I'd be happy to use a cut-down line editing library on Windows if someone could do the work of making sure it did something reasonable in all the environments we're interested in (windows command shell, cygwin terminal window, xterm). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #696: segmentation fault in ./genprimopcode (x86_64)
#696: segmentation fault in ./genprimopcode (x86_64) -+-- Reporter: taral | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.4.2 Component: Compiler (NCG) |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Os: Linux Difficulty: Unknown | Architecture: x86_64 (amd64) -+-- Changes (by simonmar): * milestone: = 6.4.2 * owner: = simonmar -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/696 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #697: Bad assembler generated
#697: Bad assembler generated -+-- Reporter: taral | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) |Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Os: Linux Difficulty: Unknown | Architecture: x86_64 (amd64) -+-- Changes (by simonmar): * resolution: = fixed * status: new = closed Comment: I fixed the out-of-range addqs recently: Thu Feb 9 16:22:47 GMT 2006 Simon Marlow [EMAIL PROTECTED] * x86_64: fix case of out-of-range operands to leaq M ./ghc/compiler/nativeGen/MachCodeGen.hs -3 +8 The movl %esi, %esi is not a NOP in x86_64, it is actually a zero- extension from 32 to 64 bits in the esi/rsi register. x86_64 assembly is pretty strange, sometimes. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/697 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Os: Linux Difficulty: Unknown | Architecture: x86 -+-- Changes (by simonmar): * component: Compiler (FFI) = Runtime System * priority: normal = low * summary: allocaBytes does not actually free the memory after the computation = GHC's internal memory allocator never releases memory back to the OS Comment: I've changed $(subject), this bug is actually just an instance of the more general problem that GHC never releases any memory back to the OS. The memory allocated by allocaBytes has actually been freed, but it is still held by GHC's memory allocator, and not the OS. Normally this isn't a big problem, because the memory will be re-used by GHC. However, in cases where you have a large spike in memory use or want to temporarily allocate a very large object, it becomes noticeable. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/698 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime System|Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Linux Difficulty: Moderate (1 day) | Architecture: Multiple ---+ Changes (by simonmar): * architecture: x86 = Multiple * difficulty: Unknown = Moderate (1 day) -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/698 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #699: GHCi doesn't implement foreign import on amd64 when interpreting.
#699: GHCi doesn't implement foreign import on amd64 when interpreting. ---+ Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal| Milestone: 6.6 Component: GHCi |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Multiple Difficulty: Moderate (1 day) | Architecture: x86_64 (amd64) ---+ Changes (by simonmar): * difficulty: Unknown = Moderate (1 day) * milestone: = 6.6 * owner: = simonmar * os: Linux = Multiple Comment: We know about this (a bunch of tests are failing because of it). Thanks for raising the ticket, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/699 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: The make problem
Ian Lynagh wrote: It looks like the make problem is not going to be fixed in the next release of make (and the current release only works because of a bug): https://savannah.gnu.org/bugs/?func=detailitemitem_id=15584 I'm afraid I haven't followed carefully enough to know what the problem is exactly, or how to fix it. I skimmed through the discussion. I wonder if someone who has a testbed set up for this could try to find a workaround - first thing to try would be to disable the empty .SECONDARY target in $TOP/mk/suffix.mk. As I understand it, this is what's happening: the empty .SECONDARY target says build everything you can, even intermediate files. So make is traversing the entire dependency graph to find things to build, even though it has already figured out that it can't build the final target. Furthermore, because it isn't caching the results of this traversal, it ends up traversing the graph many times. I think we can safely do away with .SECONDARY, it was there to avoid make's mildly annoying habit of deleting intermediate files, but it's only a debugging issue (we like to see those intermediate files sometimes), it shouldn't cause any extra rebuilding to happen. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #700: Inconsistent typechecking of pattern match in function binding
#700: Inconsistent typechecking of pattern match in function binding ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: lowest| Milestone: Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonpj): * priority: normal = lowest Comment: Yes, this is a little-used feature that I removed subsequent to GHC 6.4. Implementing it requires instantiation inside patterns, which was jolly tricky to implement, and all the more so when combined with GADTs etc. And the pain just didn't seem worth the gain; are you really going to have arguments with type (forall a. Maybe a)? Bottom line: I don't propose to change this unless there are some pretty convincing examples of how useful it'd be. I'm guessing they are hard to find, but I could be wrong. I'll leave this open, but with verylow priority Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/700 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
