panic when compiling SHA

[Carter Schonwald]

Adam,
I agree that it should be considered a misfeature (or at the very least a
good stress test that currently breaks the register allocator). That said,
INLINE / INLINEABLE are only needed for intermodule optimization, have you
tried using the special "inline" primop selectively, or using INLINEABLE
plus selective inline? I think inline should work in the defining module
even if you don't provide an INLINE or INLINEABLE.

question 1: does the code compile well when you use -fllvm? (seems like the
discussion so far has been NCG focused).
how does the generated assembly fair that way vs the workaroudn path on NCG?




On Tue, Jan 7, 2014 at 6:57 PM, Adam Wick <awick at galois.com> wrote:

> On Jan 7, 2014, at 2:27 AM, Ben Lippmeier <benl at ouroborus.net> wrote:
> > On 07/01/2014, at 9:26 , Adam Wick <awick at galois.com> wrote:
> >
> >>> Not if we just have this one test. I'd be keen to blame excessive use
> of inline pragmas in the SHA library itself, or excessive optimisation
> flags. It's not really a bug in GHC until there are two tests that exhibit
> the same problem.
> >>
> >> The SHA library uses SPECIALIZE, INLINE, and bang patterns in fairly
> standard ways. There’s nothing too exotic in there, I just basically
> sprinkled hints in places I thought would be useful, and then backed those
> up with benchmarking.
> >
> > Ahh. It's the "sprinkled hints in places I thought would be useful"
> which is what I'm concerned about. If you just add pragmas without
> understanding their effect on the core program then it'll bite further down
> the line. Did you compare the object code size as well as wall clock
> speedup?
>
> I understand the pragmas and what they do with my code. I use SPECIALIZE
> twice for two functions. In both functions, it was clearer to write the
> function as (a -> a -> a -> a), but I wanted specialized versions for the
> two versions that were going to be used, in which (a == Word32) or (a ==
> Word64). This benchmarked as faster while maintaining code clarity and
> concision. I use INLINE in five places, each of them a SHA step function,
> with the understanding that it would generate ideal code for a compiler for
> the performance-critical parts of the algorithm: straight line,
> single-block code with no conditionals.
>
> When I did my original performance work, several versions of GHC ago, I
> did indeed consider compile time, runtime performance, and space usage. I
> picked what I thought was a reasonable balance at the time.
>
> I also just performed an experiment in which I took the SHA library,
> deleted all instances of INLINE and SPECIALIZE, and compiled it with HEAD
> on 32-bit Linux. You get the same crash. So my usage of SPECIALIZE and
> INLINE is beside the point.
>
> > Sadly, "valid input" isn't a well defined concept in practice. You could
> write a "valid" 10GB Haskell source file that obeyed the Haskell standard
> grammar, but I wouldn't expect that to compile either.
>
> I would. I’m a little disappointed that ghc-devs does not. I wouldn’t
> expect it to compile quickly, but I would expect it to run.
>
> > You could also write small (< 1k) source programs that trigger
> complexity problems in Hindley-Milner style type inference. You could also
> use compile-time meta programming (like Template Haskell) to generate
> intermediate code that is well formed but much too big to compile. The fact
> that a program obeys a published grammar is not sufficient to expect it to
> compile with a particular implementation (sorry to say).
>
> If I write a broken Template Haskell macro, then yes, I agree. This is not
> the case in this example.
>
> > Adding an INLINE pragma is akin to using compile-time meta programming.
>
> Is it? I find that a strange point of view. Isn’t INLINE just a strong
> hint to the compiler that this function should be inlined? How is using
> INLINE any different from simply manually inserting the code at every call
> site?
>
>
> - Adam
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140108/fa94fbe6/attachment.html>