aboutsummaryrefslogtreecommitdiff
path: root/test/notinheap3.go
AgeCommit message (Collapse)Author
2018-12-05cmd/compile: omit write barriers for slice clears of go:notinheap pointersAustin Clements
Currently, for i := range a { a[i] = nil } will compile to have write barriers even if a is a slice of pointers to go:notinheap types. This happens because the optimization that transforms this into a memclr only asks it a's element type has pointers, and not if it specifically has heap pointers. Fix this by changing arrayClear to use HasHeapPointer instead of types.Haspointers. We probably shouldn't have both of these functions, since a pointer to a notinheap type is effectively a uintptr, but that's not going to change in this CL. Change-Id: I284b85bdec6ae1e641f894e8f577989facdb0cf1 Reviewed-on: https://go-review.googlesource.com/c/152723 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2017-11-06cmd/compile: []T where T is go:notinheap does not need write barriersAustin Clements
Currently, assigning a []T where T is a go:notinheap type generates an unnecessary write barrier for storing the slice pointer. This fixes this by teaching HasHeapPointer that this type does not have a heap pointer, and tweaking the lowering of slice assignments so the pointer store retains the correct type rather than simply lowering it to a *uint8 store. Change-Id: I8bf7c66e64a7fefdd14f2bd0de8a5a3596340bab Reviewed-on: https://go-review.googlesource.com/76027 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-29cmd/compile: elide write barriers for copy of notinheap pointersAustin Clements
Currently copy and append for types containing only scalars and notinheap pointers still get compiled to have write barriers, even though those write barriers are unnecessary. Fix these to use HasHeapPointer instead of just Haspointer so that they elide write barriers when possible. This fixes the unnecessary write barrier in runtime.recordspan when it grows the h.allspans slice. This is important because recordspan gets called (*very* indirectly) from (*gcWork).tryGet, which is go:nowritebarrierrec. Unfortunately, the compiler's analysis has no hope of seeing this because it goes through the indirect call fixalloc.first, but I saw it happen. Change-Id: Ieba3abc555a45f573705eab780debcfe5c4f5dd1 Reviewed-on: https://go-review.googlesource.com/73413 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-10-29cmd/compile: make HasHeapPointer recursiveAustin Clements
Currently (*Type).HasHeapPointer only ignores pointers go:notinheap types if the type itself is a pointer to a go:notinheap type. However, if it's some other type that contains pointers where all of those pointers are go:notinheap, it will conservatively return true. As a result, we'll use write barriers where they aren't needed, for example calling typedmemmove instead of just memmove on structs that contain only go:notinheap pointers. Fix this by making HasHeapPointer walk the whole type looking for pointers that aren't marked go:notinheap. Change-Id: Ib8c6abf6f7a20f34969d1d402c5498e0b990be59 Reviewed-on: https://go-review.googlesource.com/73412 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>