profile
viewpoint

jake-ciolek/gofuzz 0

Fuzz testing for go.

startedWesleyAC/deeplinks

started time in a month

startedchromedp/examples

started time in a month

startedprabhatsharma/zinc

started time in a month

startedGoogleCloudPlatform/k8s-metadata-proxy

started time in 2 months

startedm1k1o/neko

started time in 2 months

startedNagyD/SDLPoP

started time in 2 months

issue openedgolang/go

cmd/compile: Duplicated sequence of instructions in runtime.adjustframe on AMD64

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> go tip </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> Darwin AMD64 </pre></details>

What did you do?

Looked at the assembly code of runtime.adjustframe.

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

movl	$1, %eax
movq	128(%rsp), %rbp
addq	$136, %rsp
retq

I expected to see this once since there's a ret.

What did you see instead?

movl	$1, %eax
movq	128(%rsp), %rbp
addq	$136, %rsp
retq
movl	$1, %eax
movq	128(%rsp), %rbp
addq	$136, %rsp
retq
movl	$1, %eax
movq	128(%rsp), %rbp
addq	$136, %rsp
retq

Perhaps I am missing something and there's a valid reason for this, but it seems to me that we could use this sequence once and save 40+ bytes of instructions. Not sure if it's occuring anywhere else.

created time in 3 months

issue commentgolang/go

cmd/compile: Get rid of redundant TEST instructions by using the ZF flag of DEC/INC

There's another thing, for which I think I'll start a new issue where we generate code that prevents macro-op fusion because there's an instruction between TEST and a JUMP or a CMP and a JUMP. That instruction could be put before TEST/CMP and the execution of the program wouldn't change, but the speed would increase.

jake-ciolek

comment created time in 3 months

issue commentgolang/go

cmd/compile: Get rid of redundant TEST instructions by using the ZF flag of DEC/INC

@ulikunitz

I believe reducing code size will improve performance, for example this change where we replace longer forms of AND with a shorter one clearly boosted performance:

https://go-review.googlesource.com/c/go/+/354970

Additionally, even though TEST/JUMP fuses, DEC/JUMP fuses too. Putting a test in between makes A DEC/TEST/JUMP execute one extra instruction.

The same goes for AND, ADD and SUB.

jake-ciolek

comment created time in 3 months

startedv8/v8

started time in 3 months

issue commentgolang/go

cmd/compile: Get rid of redundant TEST instructions by using the ZF flag of DEC/INC

I think it might go even beyond arithmetic. I've looked at doing this for AND(Q|L)const/XOR(Q|L)const , but ran into issues related to handling blocks...

I've changed the Op definition so it emitted two values (Uint and Flags) but was unable to make it work for some reason.

I think we could get a lot of speedup on x86 by doing this.

jake-ciolek

comment created time in 3 months

issue openedgolang/go

cmd/compile: Get rid of redundant TEST instructions by using the ZF flag of DEC/INC

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> go tip </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> GO111MODULE="" GOARCH="amd64" GOBIN="" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOSUMDB="sum.golang.org" GOTMPDIR="" GOVCS="" GOVERSION="devel go1.18-9ff91b9098 Fri Oct 22 00:57:18 2021 +0000" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/dev/null" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7d/d_44vx7920vfy_tmc_l6xgprjh03ym/T/go-build2772586434=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

Dumped the Go assembly itself, but this happens for anything compiled with gc.

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

The compiler making use of the ZF flag value when emitting DEC(Q|L) / INC(Q|L) instructions.

What did you see instead?

Redundant TEST(Q|L) instructions for checking if the result is zero, for example:

 _math/big.nat.shl:
 
decq	%rdx
testq	%rdx, %rdx
 
 _cmd/go/internal/work.(*Builder).Do.func3:
 
decl	%esi
testl	%esi, %esi
 
 _go/token.(*FileSet).file:
 
incl	%edx
testl	%edx, %edx
 
 _cmd/go/internal/work.gcToolchain.gc:
 
incq	%r9
testq	%r9, %r9

test/jz macro-op fuses but we could get rid of testq to save some CPU cache space / reduce front-end pressure.

I have looked into this briefly and it seems that it might be better to move the INC/DEC implementation to AMD64.rules instead? Currently it's handled in a special way inside of cmd/cmpile/internal/amd64/ssa.go

created time in 3 months

more