On 08/01/14 07:35, Carter Schonwald wrote:
well said iavor.
It perhaps hints at the register allocators needing some love? I hope to
dig deep into those myself later this year, but maybe it needs some
wibbles to clean up for 7.8 right now?
There's a bit of confusion here. Let me try to clarify:
- the graph-colouring register allocator now trips the spill slot
limit with SHA-1, where it didn't previously. This may be
because earlier compiler stages are generating worse code, or
it may be because this allocator has bitrotted (see #7679).
- The code compiles fine without the flag -fregs-graph.
- The limitation on spill slots that existed in all versions prior to
7.8 has been lifted in 7.8, but only for the linear register
allocator (the default one that you get without -fregs-graph).
So, let's just disable -fregs-graph in 7.8.1.
Ben is right that avoiding -fregs-graph doesn't really fix the problem,
because we'll probably get crappy code for SHA-1 now. But someone needs
to work on -fregs-graph.
This ticket is for the performance issue:
https://ghc.haskell.org/trac/ghc/ticket/7679
And I just created this one for the spill slot issue:
https://ghc.haskell.org/trac/ghc/ticket/8657
Cheers,
Simon
On Wed, Jan 8, 2014 at 2:14 AM, Iavor Diatchki <[email protected]
<mailto:[email protected]>> wrote:
Hello,
I find it a bit perplexing (and not at all constructive) that we are
arguing over semantics here. We have a program (1 module, ~1000
lines of "no fancy extension Haskell"), which causes GHC to panic.
This is a bug. An invariant that we were assuming did not
actually hold. Hence the message that the "impossible" happened.
If GHC decides to refuse to compile a program, it should not panic
but, rather, explain what happened and maybe suggest a workaround.
I am not familiar with GHC's back-end, but it seems that there might
be something interesting that's going on here. The SHA library
works fine with 7.6.3, and it compiles (admittedly very slowly)
using GHC head on my 64-bit machine. So something has changed, and
it'd be nice if we understood what's causing the problem.
Ben suggested that the issue might be the INLINE pragmas, but
clearly that's not the problem, as Adam reproduced the same behavior
without those pragmas. If the issue is indeed with the built-in
inline heuristics, it sounds like we either should fix the
heuristics, or come up with some suggestions about what to avoid in
user programs. Or, perhaps, the issue something completely
unrelated (e.g., a bug in the register allocator). Either way, I
think this deserves a ticket.
-Iavor
On Tue, Jan 7, 2014 at 10:11 PM, Carter Schonwald
<[email protected] <mailto:[email protected]>> wrote:
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]
<mailto:[email protected]>> wrote:
On Jan 7, 2014, at 2:27 AM, Ben Lippmeier
<[email protected] <mailto:[email protected]>> wrote:
> On 07/01/2014, at 9:26 , Adam Wick <[email protected]
<mailto:[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] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
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
