GHC on IA-64

[Simon Marlow]

Thanks for the analysis Duncan.  Would you mind submitting a ticket for 
this?

What does the crash look like in gdb?  Does it look like it has jumped 
into the middle of nowhere, or is it a crash in some actual code that 
you can disassemble?  To find out what was happening just before the 
crash, the recipe is usually:

   - make it deterministic: +RTS -C0

   - set a breakpoint in a common basic block, eg. stg_upd_frame_info,
     stg_upd_frame_1_info, stg_ap_p_info.

   - ignore 1 9999999, run, info break, ignore 1 N-1, run (where N is the
     number of times the breakpoint was hit).

   - single step forwards to find out what was going on just before the
     crash.  If you have to single step a long way, it might be better
     to pick a different breakpoint - take note of which code blocks
     you step through.

Cheers,
	Simon

Duncan Coutts wrote:
> On Sat, 2006-03-25 at 21:29 +0000, Duncan Coutts wrote:
> 
> 
>>If anyone wants to look into it, I could narrow down the threshold of
>>the -funfolding-use-threshold flag at which the bug is triggered and
>>compare the assembly output.
> 
> 
> I found the threshold is 14-15. With -funfolding-use-threshold14 it
> works ok and with -funfolding-use-threshold15 the mangler complains as
> in my original message.
> 
> Here is the assembly output for them both:
> http://haskell.org/~duncan/ghc/ia64/SHA1-unfold14.raw_S
> http://haskell.org/~duncan/ghc/ia64/SHA1-unfold15.raw_S
> 
> This does seem to be a critical unfolding threshold since the file sizes
> are dramatically different. On the other hand, much of the two are the
> same (modulo symbol names).
> 
> In the case that breaks the mangler (SHA1-unfold15.raw_S) you can see
> there is a function that has a massive straight line section of code.
> 
> It is the crossing of this unfolding threshold that seems to have
> allowed the second version to inline almost everything and give nice
> short straight line code.
> 
> The specific bit that the mangler complains about is in
> SHA1-unfold15.raw_S line 1304.
> 
> Prologue junk?:         .proc s60A_ret#
> s60A_ret:
>         .save ar.pfs, r107
>         alloc r107 = ar.pfs, 0, 77, 8, 0
>         .body
> 
> The whole bit is:
> s60A_ret:
> 	.prologue 12, 106
> 	.save ar.pfs, r107
> 	alloc r107 = ar.pfs, 0, 77, 8, 0
> 	mov r108 = r1
> 	.save rp, r106
> 	mov r106 = b0
> 	.body
> 	;;
> 
> Which is not dramatically different from the same bit from
> SHA1-unfold14.raw_S:
> 
> s5pF_ret:
> 	.prologue 12, 61
> 	.save ar.pfs, r62
> 	alloc r62 = ar.pfs, 0, 32, 0, 0
> 	mov r63 = r1
> 	.save rp, r61
> 	mov r61 = b0
> 	.body
> 	;;
> 
> Interestingly, all other alloc directives in both versions are exactly:
> alloc r62 = ar.pfs, 0, 32, 0, 0
> There is only that one occurrence of
> alloc r107 = ar.pfs, 0, 77, 8, 0
> in the whole of SHA1-unfold15.raw_S
> 
>>From looking at the Evil Mangler it is clear that it does not expect the
> different form of alloc directive:
> 
> elsif ($TargetPlatform =~ /^ia64-/) {
>                     $p =~ s/^\t\.prologue .*\n//;
>                     $p =~ s/^\t\.save ar\.pfs, r\d+\n\talloc r\d+ = ar
> \.pfs, 0, 3[12], \d+, 0\n//;
> 
> So if we relax the regexp from 3[12] to just \d+ then the mangler no
> longer barfs.
> 
> Unfortunately it seems that when recompiled with this change to the
> mangler and the original -funfolding-use-threshold20, darcs dies with an
> illegal instruction error when performing some repo operations. I need
> more help to figure out in gdb what's going on. I couldn't figure out
> how to get a disassembly in gdb of the code executing just before the
> error.
> 
> So it's not clear if this illegal instruction bug is caused by my
> mangler change or if it's just another effect of the extreme unfolding.
> 
> With the -funfolding-use-threshold flag removed, darcs builds and passes
> 98% of the its test suite.
> 
> Duncan