#4308: LLVM compiles Updates.cmm badly
---------------------------------+------------------------------------------
Reporter: dterei | Owner: dterei
Type: bug | Status: new
Priority: normal | Milestone: 7.2.1
Component: Compiler (LLVM) | Version: 6.13
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Comment(by dterei):
Replying to [comment:7 simonmar]:
> Yes, we do need to do this, and we've discussed doing it in the new
backend, but if you have to wait for that it could be a while.
Could we not do this in the old/current codegen? I can't imagine its that
much work, I haven't look at the old/current codegen yet but I would
assume there is some fairly easy way to access the live stg register
information.
> Why not in the meantime propagate the information about dead STG
registers yourself, from the foreign call to the final downstream tail-
calls? Presumably this could be done with a pass over the LLVM
intermediate code.
True. I thought about using this approach and actually I have a patch in
my local branch that does 'kind' of this. I say kind of since to do it
properly you need to process the function in control flow order and my
local patch doesn't do this, instead just does a few tricks/hacks to avoid
needing to determine control flow.
I thought it would actually be simpler to implement the live stg register
info approach then do propagation. The live approach has the advantage of
freeing up a lot of registers for most functions since really R3 ... R6,
F3, F4... aren't in use a lot of the time.
If I was to do propagation how do you suggest I process a function in
control flow order? Just write some code to do this myself or is there an
existing framework in ghc? (e.g maybe even use Hoopl?)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4308#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
