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 <[email protected]> wrote: > On Jan 7, 2014, at 2:27 AM, Ben Lippmeier <[email protected]> wrote: > > On 07/01/2014, at 9:26 , Adam Wick <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
