cmd/compile: Could make better use of "bimm64" on ARM64 #19857
Labels
Comments
|
Generic rule rewrites certain AND to shifts and we didn't undo this in ARM64 rules. Should we? |
|
We could, it would be easy, just augment the (new) rule that converts (LSR k(LSL k x)) into (ROR k (LSL k x)) into one that uses the AND. I think no need to check the usage of the LSL because if it's > 1 that means the instruction count remains the same. |
|
Yeah, I did this. It also reveals a (performance) bug in the assembler backend that some constants did not get encoded into instruction although it could. CLs are coming. |
|
CL https://golang.org/cl/39651 mentions this issue. |
|
CL https://golang.org/cl/39652 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Apr 6, 2017
When a constant is both MOVCON (can fit into a MOV instruction) and BITCON (can fit into a logical instruction), the assembler chooses to use the MOVCON encoding, which is actually longer for logical instructions. We add MBCON rules explicitly to make sure it uses the BITCON encoding. Updates #19857. Change-Id: Ib9881be363cbc491ac2a0792b36b87e74eff34a8 Reviewed-on: https://go-review.googlesource.com/39652 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
lparth
pushed a commit
to lparth/go
that referenced
this issue
Apr 13, 2017
For an AND that masks out leading or trailing bits, generic rules rewrite it to a pair of shifts. On ARM64, the mask actually can fit into an AND instruction. So we rewrite it back to AND. Fixes golang#19857. Change-Id: I479d7320ae4f29bb3f0056d5979bde4478063a8f Reviewed-on: https://go-review.googlesource.com/39651 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
lparth
pushed a commit
to lparth/go
that referenced
this issue
Apr 13, 2017
When a constant is both MOVCON (can fit into a MOV instruction) and BITCON (can fit into a logical instruction), the assembler chooses to use the MOVCON encoding, which is actually longer for logical instructions. We add MBCON rules explicitly to make sure it uses the BITCON encoding. Updates golang#19857. Change-Id: Ib9881be363cbc491ac2a0792b36b87e74eff34a8 Reviewed-on: https://go-review.googlesource.com/39652 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?1.9devel
What operating system and processor architecture are you using (
go env)?ARM64
What did you do?
Compiled
x & ((1<<63)-1)We currently convert this to a
(LSR 1 (LSL 1 x))because that is more efficient than loading the immediate.
However, 64-bit AND apparently takes a "bimm64" operand which can contain some not entirely well specified runs of 0 and 1, that happens to include
((1<<63)-1). This came from an investigation into whether the problematic idiom described in #19809 might occur in code compiled from C or C++. I discovered that it does not, and that the operand can be expressed compactly as an immediate to logical operations.I don't yet know if the Go assembler handles bimm64; the bug is filed so as not to forget this.
The text was updated successfully, but these errors were encountered: