> > > rje 2003/03/18 15:24:20 PST > > > > Modified files: (Branch: speceval_2) > > ghc/compiler/absCSyn AbsCSyn.lhs AbsCUtils.lhs PprAbsC.lhs > > ghc/compiler/codeGen CgBindery.lhs CgCase.lhs CgClosure.lhs > > CgCon.lhs CgExpr.lhs CgMonad.lhs > > CgRetConv.lhs CgTailCall.lhs > > ghc/compiler/main Constants.lhs > > ghc/compiler/nativeGen AbsCStixGen.lhs StixPrim.lhs > > Log: > > This commit adds bitwise semitagging to the speculative branch. > > Very cool! > > I suspect there will be *lots* of changes in the RTS to make this go. > We might want to see if we can use an abstract type for "possibly tagged > closure pointers" in C to make things clearer / less fragile and to help > flag code that might need to be changed.
Good point. Will do. > I'd like to test this stuff independently of spec-eval - I have a > feeling it might be an improvement on its own. Any chance of getting a > patch for the HEAD? When I implemented a similar change previously (in my old non-CVS speceval branch) results suggested that it made little difference to non-speculative execution. The problem was that most closures were either thunks, or, if they had already been evaluated, indirections. As a result, semitagging usually failed and so didn't on average win anything. By contrast, when execution is speculative, most closures are values and so semitagging usually succeeds. I can still do a patch for the HEAD if you like (though it would have to wait a bit as I'm currently in a paper panic), but I suspect that, if speculation isn't in the tree as well, it would just be an unnecessary extra layer of complexity. -Rob _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
