November 2005 - Glasgow-haskell-users

RE: jhc vs ghc and the surprising result involving ghcgeneratedassembly.
by Simon Marlow 02 Nov '05

02 Nov '05

On 02 November 2005 13:59, Florian Weimer wrote: > However, beginning with GCC 3.4, you can use: > > extern void bar(); > > void foo() > { > void (*p)(void) = bar; > p(); > } Interesting.. though I'm not sure I'm comfortable with relying on gcc's tail call optimisation to do the right thing. Aren't there side conditions that might prevent it from kicking in? > And the indirect call is turned into a direct jump. Tail recursive > calls and really indirect tail calls are also optimzed. Together with > -fomit-frame-pointer, this could give you what you need, without > post-processing the generated assembler code (which is desirable > because the asm volatile statements inhibit further optimization). > > Is it correct that you use indirect gotos across functions? Such > gotos aren't supported by GCC and work only by accident. Yes, but cross-function gotos are always to the beginning of a function. Also, our post-processor removes the function prologue from the asm. GHC via C has always worked "by accident" :-) But it has worked for a long time with careful tweaking of the post-processor (known as the mangler) for each new version of gcc. Yes, we're living dangerously, and it's getting harder, but we're still alive (just). Cheers, Simon

3 3

Array operations and pinning
by Rene de Visser 02 Nov '05

02 Nov '05

Hello, Where is the documentation on how pinning works in the GHC garbage collector (from a GHC users point of view). I have copied the following code from array/IO.hs and am thinking that it is assuming that the array is pinned? What triggers the pinning? On a second note. Why is the type signiture so constricted. The code below works on any IOUArray (which is very usefull, not just on Int Word8). Naturally this assumes the particular in memory array layout that GHC uses on a particular platform, so would not be compatible (probably) with other Haskell compilers. Rene. hPutArray :: Handle -- ^ Handle to write to -> IOUArray Int Word8 -- ^ Array to write from -> Int -- ^ Number of 'Word8's to write -> IO () hPutArray handle (IOUArray (STUArray l u raw)) count | count == 0 = return () | count < 0 || count > rangeSize (l,u) = illegalBufferSize handle "hPutArray" count | otherwise = do wantWritableHandle "hPutArray" handle $ \ handle_@Handle__{ haFD=fd, haBuffer=ref, haIsStream=stream } -> do old_buf@Buffer{ bufBuf=old_raw, bufRPtr=r, bufWPtr=w, bufSize=size } <- readIORef ref -- enough room in handle buffer? if (size - w > count) -- There's enough room in the buffer: -- just copy the data in and update bufWPtr. then do memcpy_baoff_ba old_raw w raw (fromIntegral count) writeIORef ref old_buf{ bufWPtr = w + count } return () -- else, we have to flush else do flushed_buf <- flushWriteBuffer fd stream old_buf writeIORef ref flushed_buf let this_buf = Buffer{ bufBuf=raw, bufState=WriteBuffer, bufRPtr=0, bufWPtr=count, bufSize=count } flushWriteBuffer fd stream this_buf return ()

1 0

RE: jhc vs ghc and the surprising result involving ghc generatedassembly.
by Simon Marlow 02 Nov '05

02 Nov '05

John, this is great stuff. There's clearly a lot we can do to improve GHC's code, at least for fac :-) (I'd be really interested in any numbers you have for larger programs too, eg. the nofib suite). > and now the generated assembly. > > Main_zdwfac_info: > .text > .align 8 > .text > movq (%rbp), %rdx > cmpq $1, %rdx > jne .L2 > movq 8(%rbp), %r13 > leaq 16(%rbp), %rbp > movq (%rbp), %rax > .L4: > jmp *%rax gcc started generating this rubbish around version 3.4, if I recall correctly. I've tried disabling various optimisations, but can't seem to convince gcc not to generate the extra jump. You don't get this from the native code generator, BTW. Actually, our NCG beats gcc in most cases on x86_64, I believe. > .L2: > movq %rdx, %rax > imulq 8(%rbp), %rax > movq %rax, 8(%rbp) > leaq -1(%rdx), %rax > movq %rax, (%rbp) > movl $Main_zdwfac_info, %eax > jmp .L4 [snip] > A couple simple rules seem to help greatly. > > * turn anything of the form JMP_((W_)&self) where self is oneself into a goto > that gotos a label at the beginning of the function. Sounds like a good idea. In fact, we should do all this as a C-- -> C-- optimisation, as Simon PJ pointed out (and I mentioned on IRC yesterday). one small caveat: our register allocator can't handle loops at the moment, so any optimisations that generated actual loops would have to be disabled for the NCG for now. > * do simple pattern matthing on the basic blocks to recognize where C control > constructs can be placed. > > for instance turn > > if (x) { goto y; } > blah.. > baz.. > JMP_(foo) > > into > > if (x) { goto y; } else { > blah.. > baz.. > JMP_(foo) > } I don't actually understand why this helps, but it's easy enough to do. > * getting stack dereferences out of your loops. A bit more tricky, but could still be done as C-- to C--. Note that GHC's back end is really aimed at producing good code when there are registers available for passing arguments - this isn't true on x86 or x86_64 at the moment, though. > 1. fully convert it to use C control constructs, so gcc will do it for us. > (code motion and loop invarient being inhibited again by gotos) Ok. Jan's do-while idea seems like a cheap way to achieve this. > These should be straightforward to implement in the C code generator. it also > suggests we might want to try to use the native C calling convention on leaf > nodes that deal with unboxed values (so we get register passing and return > values for free) or taking groups of mutually recursive functions and turning > them all into one function with explicit jumps between them. Using the real C calling convention brings some problems - we'd have to use setjmp/longjmp to pass control back to the scheduler or garbage collector. Cheers, Simon

4 4