info tables are no longer aligned

Take a simple program like

main = mapM_ print "Hello, world"

and build with -O.

Versions of ghc as late as 7.11.20150806 generate assembly that includes

...
_c3mn:
	movq $sat_s3m2_info,-16(%r12)
	movq %r14,(%r12)
	movq $block_c3mi_info,-16(%rbp)
	movl $GHC.Types.True_closure+2,%edi
	movq %rsi,%rax
	leaq -16(%r12),%rsi
	movl $GHC.IO.Handle.FD.stdout_closure,%r14d
	movq %rax,-8(%rbp)
	addq $-16,%rbp
	jmp GHC.IO.Handle.Text.hPutStr2_info
.text
	.align 8
	.quad	1
	.quad	32
block_c3mi_info:
_c3mi:
	movq 8(%rbp),%rbx
	addq $16,%rbp
	jmp stg_ap_v_fast
...

Note the .align 8 ensuring that the info table (and the code _c3mi itself) is 8-byte aligned.

In 8.1.20160107 we instead get

_c5gE:
	movq $sat_s5g9_info,-16(%r12)
	movq %r14,(%r12)
	movq $block_c5gz_info,-16(%rbp)
	movl $GHC.Types.True_closure+2,%edi
	movq %rsi,%rax
	leaq -16(%r12),%rsi
	movl $GHC.IO.Handle.FD.stdout_closure,%r14d
	movq %rax,-8(%rbp)
	addq $-16,%rbp
	jmp GHC.IO.Handle.Text.hPutStr2_info
_c5gF:
	movq $24,904(%r13)
_c5gC:
	movl $Main.main2_closure,%ebx
	jmp *-8(%r13)
	.quad	1
	.quad	32
block_c5gz_info:
_c5gz:
	movq 8(%rbp),%rbx
	addq $16,%rbp
	jmp stg_ap_v_fast
	.size Main.main2_info, .-Main.main2_info

There is some minor rearrangement, but more importantly there is no longer any .align 8 before .quad 1. That means the info table is not necessarily aligned, and indeed c5gz_info ended up at the address 40676f.

I'm guessing this is bad for performance, though I don't know how bad.

I'm pretty sure this is due to 4a32bf92 "Implement function-sections for Haskell code" though I haven't looked at that commit in detail.

Trac metadata

Trac field	Value
Version	8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	high
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	olsner
Operating system
Architecture

changed milestone to %8.0.1

changed weight to 7

added Tbug Trac import labels

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → RuntimePerformance

Simon O, Simon M, it'd b good to nail this. Looks bad to me. Well spotted Reid.

I suspect the issue here is the pprSectionHeader removed from pprBasicBlock.

@@ -113,7 +109,6 @@ pprBasicBlock info_env (BasicBlock blockid instrs)
     maybe_infotable = case mapLookup blockid info_env of
        Nothing   -> empty
        Just (Statics info_lbl info) ->
-           pprSectionHeader Text $$
            infoTableLoc $$
            vcat (map pprData info) $$
            pprLabel info_lbl

Possibly fixed in D1846.

Trac metadata

Trac field	Value
Differential revisions	- → D1846

More thorough fix in D1847.

Trac metadata

Trac field	Value
Differential revisions	D1846 → D1847

mentioned in commit 0dc7b36c

added 1 deleted label

closed

Merged as 7a70f980.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

removed 1 deleted label

This had a small, but mostly beneficial effect on performance: https://perf.haskell.org/ghc/#revision/0dc7b36c

As expected, there is a code size cost, which has an indirect performance cost as well (since density of real code in the instruction cache is lower).

Not exactly germane to this ticket, but perhaps it would be worth experimenting with half-word-aligned info tables? Many of the info table fields are half-word-sized anyways.

added Phigh label