I'm curious about the plans forward with this. Test-bed to improve 'stock' GHC & back-end(s)? An actual full-fledged (& maintained) back-end? ...

Nicolas

On Jul 3, 2013 8:48 PM, "Ryan Newton" <rrnewton@gmail.com> wrote:
>
> This came up randomly because of a typo, but rather than respond for them I've changed the thread name to something descriptive and copies the authors of the paper.
>
> The small bit that I know:
> It is a new backend that takes Core from GHC and does the rest itself (including having a non-GHC runtime).
> There are some patches to GHC (somewhere?) to support a new kind of initialization-only vector.
> The IFLC backend uses a strict intermediate representation and performs auto-vectorization on loops.  In particular, the paper evaluates the technique on loops from (slightly modified) REPA and vector library code.
> It handles a pretty sizable subset of the language, but is missing some things (e.g. asynchronous exceptions).
> It is not released yet
> On Tue, Jul 2, 2013 at 7:54 PM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
>>
>> What branch is that work in? I've not seen mention of it in the commit logs.  I'd really love to see how they're Doing it. 
>>
>> Likewise, it's worth remarking that a carefullywritten simd primop that explicitly uses the instruction intrinsics can easily be 1.5-2x faster than auto vectorized simd code.  I've some examples I tested for matrix multiplication where the performance is robustly In that range. 
>>
>>
>> On Tuesday, July 2, 2013, Ryan Newton wrote:
>>>
>>> Gosh, sorry, yes it's not obvious from the list of accepted papers:
>>>
>>> "Automatic SIMD Vectorization for Haskell" Leaf Petersen, Dominic Orchard and Neal Glew
>>>
>>> One of the authors has a link for it but it appears there's no preprint up yet:
>>>     http://www.leafpetersen.com/leaf/publications.htm
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 2, 2013 at 5:36 AM, Nicolas Trangez <nicolas@incubaid.com> wrote:
>>>>
>>>> On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote:
>>>> > Err, GCC replacement.  But, ironically, GHC [backend] replacement as well,
>>>> > as of the recent ICFP paper.
>>>>
>>>> Got a link or reference?
>>>>
>>>> Nicolas
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>