qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-19 14:14:40 -07:00
Code Releases Activity
d91e9705f8
go/src/runtime/memclr_plan9_386.s

57 lines
899 B
ArmAsm
Raw Normal View History

runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
runtime: use new #include "textflag.h" I did this just to clean things up, but it will be important when we drop the pkg directory later. LGTM=bradfitz R=r, bradfitz CC=golang-codereviews https://golang.org/cl/132600043
2014-09-04 21:05:18 -06:00
#include "textflag.h"
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
runtime, cmd/compile: rename memclr -> memclrNoHeapPointers Since barrier-less memclr is only safe in very narrow circumstances, this commit renames memclr to avoid accidentally calling memclr on typed memory. This can cause subtle, non-deterministic bugs, so it's worth some effort to prevent. In the near term, this will also prevent bugs creeping in from any concurrent CLs that add calls to memclr; if this happens, whichever patch hits master second will fail to compile. This also adds the other new memclr variants to the compiler's builtin.go to minimize the churn on that binary blob. We'll use these in future commits. Updates #17503. Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca Reviewed-on: https://go-review.googlesource.com/31369 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
2016-10-17 16:41:56 -06:00
// void runtime·memclrNoHeapPointers(void*, uintptr)
TEXT runtime·memclrNoHeapPointers(SB), NOSPLIT, $0-8
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVL ptr+0(FP), DI
MOVL n+4(FP), BX
XORL AX, AX
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
tail:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
TESTL BX, BX
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
JEQ _0
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
CMPL BX, $2
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
JBE _1or2
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
CMPL BX, $4
runtime: memmove/memclr pointers atomically Make sure that we're moving or zeroing pointers atomically. Anything that is a multiple of pointer size and at least pointer aligned might have pointers in it. All the code looks ok except for the 1-pointer-sized moves. Fixes #13160 Update #12552 Change-Id: Ib97d9b918fa9f4cc5c56c67ed90255b7fdfb7b45 Reviewed-on: https://go-review.googlesource.com/16668 Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-11-05 13:39:56 -07:00
JB _3
JE _4
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
CMPL BX, $8
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
JBE _5through8
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
CMPL BX, $16
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
JBE _9through16
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVL BX, CX
SHRL $2, CX
REP
STOSL
ANDL $3, BX
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
JNE tail
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
RET
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
_1or2:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVB AX, (DI)
MOVB AX, -1(DI)(BX*1)
runtime: prevent pointless jmp in amd64 and 386 memmove 6a and 8a rearrange memmove such that the fallthrough from move_1or2 to move_0 ends up being a JMP to a RET. Insert an explicit RET to prevent such silliness. Do the same for memclr as prophylaxis. benchmark old ns/op new ns/op delta BenchmarkMemmove1 4.59 4.13 -10.02% BenchmarkMemmove2 4.58 4.13 -9.83% LGTM=khr R=golang-codereviews, dvyukov, minux, ruiu, bradfitz, khr CC=golang-codereviews https://golang.org/cl/120930043
2014-08-01 07:21:08 -06:00
RET
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
_0:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
RET
runtime: memmove/memclr pointers atomically Make sure that we're moving or zeroing pointers atomically. Anything that is a multiple of pointer size and at least pointer aligned might have pointers in it. All the code looks ok except for the 1-pointer-sized moves. Fixes #13160 Update #12552 Change-Id: Ib97d9b918fa9f4cc5c56c67ed90255b7fdfb7b45 Reviewed-on: https://go-review.googlesource.com/16668 Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-11-05 13:39:56 -07:00
_3:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVW AX, (DI)
runtime: memmove/memclr pointers atomically Make sure that we're moving or zeroing pointers atomically. Anything that is a multiple of pointer size and at least pointer aligned might have pointers in it. All the code looks ok except for the 1-pointer-sized moves. Fixes #13160 Update #12552 Change-Id: Ib97d9b918fa9f4cc5c56c67ed90255b7fdfb7b45 Reviewed-on: https://go-review.googlesource.com/16668 Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-11-05 13:39:56 -07:00
MOVB AX, 2(DI)
RET
_4:
// We need a separate case for 4 to make sure we clear pointers atomically.
MOVL AX, (DI)
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
RET
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
_5through8:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVL AX, (DI)
MOVL AX, -4(DI)(BX*1)
RET
[dev.power64] cmd/5a, cmd/6a, cmd/8a, cmd/9a: make labels function-scoped I removed support for jumping between functions years ago, as part of doing the instruction layout for each function separately. Given that, it makes sense to treat labels as function-scoped. This lets each function have its own 'loop' label, for example. Makes the assembly much cleaner and removes the last reason anyone would reach for the 123(PC) form instead. Note that this is on the dev.power64 branch, but it changes all the assemblers. The change will ship in Go 1.5 (perhaps after being ported into the new assembler). Came up as part of CL 167730043. LGTM=r R=r CC=austin, dave, golang-codereviews, minux https://golang.org/cl/159670043
2014-10-28 19:50:16 -06:00
_9through16:
runtime: use unoptimized memmove and memclr on Plan 9 On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
2014-03-12 19:12:25 -06:00
MOVL AX, (DI)
MOVL AX, 4(DI)
MOVL AX, -8(DI)(BX*1)
MOVL AX, -4(DI)(BX*1)
RET
Copy Permalink