Max Bolingbroke wrote:

On 18 February 2011 01:18, Johan Tibell 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 Roman

On 18/02/2011 19:42, Nathan Howell wrote:

On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy mailto:rl@cse.unsw.edu.au> wrote:

Max Bolingbroke wrote: > On 18 February 2011 01:18, Johan Tibell mailto:johan.tibell@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). Cheers, Simon

On Mon, Feb 28, 2011 at 6:29 PM, Johan Tibell wrote:

On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote:

...

On 18/02/2011 19:42, Nathan Howell wrote:

...

On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy mailto:rl@cse.unsw.edu.au> wrote:

   Max Bolingbroke wrote:     > On 18 February 2011 01:18, Johan Tibell mailto:johan.tibell@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.

You can't random-access the elements of a tuple based on an Int though, can you? You'd have to do a switch statement (pattern match) every time you wanted to access a specific element. Unless I'm missing something.

Johan

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Work is punishment for failing to procrastinate effectively.

On 01/03/2011 11:55, Roman Leshchinskiy wrote:

Simon Marlow wrote:

...

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).

Would it, in theory, be possible to have an "unpacked" array type? That is, could we have constructors for which the length of the closure is determined dynamically at runtime?

Certainly, but the amount of effort to implement depends on what you want to support. e.g. do you want to support {-# UNPACK #-} on primitive array types in a constructor field? That's probably quite hard. I believe Duncan Coutts has been thinking along similar lines, we talked about it once. Or were you thinking of something more restricted? Cheers, Simon

On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote:

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...

It's probably (certainly) better to do it in the code generator but it is rather easy to perform in LLVM and might be a worthwhile optimization during LTO/LTCG.