var glob … var globp … func TestZeroRange(t *testing.T) { … } func testZeroRange8(t *testing.T) (r int64) { … } func testZeroRange16(t *testing.T) (r, s int64) { … } func testZeroRange32(t *testing.T) (r, s, t2, u int64) { … } func testZeroRange64(t *testing.T) (r, s, t2, u, v, w, x, y int64) { … } func testZeroRange136(t *testing.T) (r, s, t2, u, v, w, x, y, r1, s1, t1, u1, v1, w1, x1, y1, z1 int64) { … } type S … type M … type L … //go:noinline func triggerZerorangeLarge(f, g, h uint64) (rv0 uint64) { … } //go:noinline func triggerZerorangeMedium(f, g, h uint64) (rv0 uint64) { … } //go:noinline func triggerZerorangeSmall(f, g, h uint64) (rv0 uint64) { … } // This test was created as a follow up to issue #45372, to help // improve coverage of the compiler's arch-specific "zerorange" // function, which is invoked to zero out ambiguously live portions of // the stack frame in certain specific circumstances. // // In the current compiler implementation, for zerorange to be // invoked, we need to have an ambiguously live variable that needs // zeroing. One way to trigger this is to have a function with an // open-coded defer, where the opendefer function has an argument that // contains a pointer (this is what's used below). // // At the moment this test doesn't do any specific checking for // code sequence, or verification that things were properly set to zero, // this seems as though it would be too tricky and would result // in a "brittle" test. // // The small/medium/large scenarios below are inspired by the amd64 // implementation of zerorange, which generates different code // depending on the size of the thing that needs to be zeroed out // (I've verified at the time of the writing of this test that it // exercises the various cases). func TestZerorange45372(t *testing.T) { … }
Codebase Browser
go