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
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
