On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow <marlo...@gmail.com> wrote: > On 18/02/2011 19:42, Nathan Howell wrote: >> >> On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy <r...@cse.unsw.edu.au >> <mailto:r...@cse.unsw.edu.au>> wrote: >> >> Max Bolingbroke wrote: >> > On 18 February 2011 01:18, Johan Tibell <johan.tib...@gmail.com >> <mailto:johan.tib...@gmail.com>> wrote:> It seems like a sufficient >> solution for your needs would be for us to >> > use the LTO support in LLVM to inline across module boundaries - in >> > particular to inline primop implementations into their call >> sites. LLVM >> > would then probably deal with unrolling small loops with >> statically known >> > bounds. >> >> Could we simply use this? >> >> http://llvm.org/docs/LangRef.html#int_memcpy >> >> >> Might be easier to implement a PrimOp inlining pass, and to run it >> before LLVM's built-in MemCpyOptimization pass [0]. This wouldn't >> generally be as good as LTO but would work without gold. >> >> [0] http://llvm.org/doxygen/MemCpyOptimizer_8cpp_source.html > > Ideally you'd want the heap check in the primop to be aggregated into the > calling function's heap check, and the primop should allocate directly from > the heap instead of calling out to the RTS allocate(). All this is a bit > much to expect LLVM to do, but we could do it in the Glorious New Code > Generator... > > For small arrays like this maybe we should have a new array type that leaves > out all the card-marking stuff too (or just use tuples, as Roman suggested).
I might try to use tuples directly. It would be very ugly though as I would need a sum type of 32 different tuple sizes. Johan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users