george, the problem with that is not all targets that ghc support have an llvm backend. (in fact, one problem I hope to help resolve (not in full mind you) for 7.10 is that theres a semi disjoint coverage across the backends)
On Thu, Jan 9, 2014 at 3:08 PM, George Colpitts <[email protected]>wrote: > Does LLVM have the same limitation that its register allocator does not > reuse spill slots for variables that have disjoint live ranges? If not, > could the library be compiled with llvm? > > > On Thu, Jan 9, 2014 at 3:17 PM, Adam Wick <[email protected]> wrote: > >> On Jan 8, 2014, at 2:42 AM, Simon Marlow <[email protected]> wrote: >> >> Neither of the register allocators reuse spill slots for variables that >> have disjoint live ranges, so the fact that we ran out of spill slots is >> not necessarily indicative of terrible code (but I agree that it's a strong >> hint). >> >> >> That’s the problem with SHA, then. The implementation (and the spec, >> really) is essentially a long combination of the form: >> >> let x_n5 = small_computation x_n1 x_n2 x_n3 x_n4 >> x_n6 = small_computation x_n2 x_n3 x_n4 x_n5 >> … >> >> Which has ~70 entries. The actual number of live variables alive at any >> time should be relatively small, but if slots aren’t getting reused there’s >> going to be some significant blowup. (To be honest, I had figured — and >> thought I had validated — that doing it this way would give the compiler >> the best chance at generating optimal code, but it appears I merely set >> myself up to hit this limitation several years later.) >> >> >> - Adam >> >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
