FAQ
Tuple types would have other uses as well, for example doing x/y and x%y
with a single instruction.

On Wed, Mar 30, 2016 at 8:31 AM, Philip Hofer wrote:

Keith suggested that we'd need tuple types in order to make the flags
output explicit in 2, since the rulegen stuff happens before instruction
scheduling. It'd be a much more modest change if we had late-stage
peephole-ing, but I'd rather the tuple stuff go in, since it will also make
a tremendous difference on arm in terms of generating conditional
instructions.

On Wednesday, March 30, 2016 at 5:20:10 AM UTC-7, ilya....@intel.com
wrote:
Hi,

Have you started converting 2?
I'm working on similar patch (going to send it today/tomorrow).

As for 3, I think we already do similar optimization.
E. g. in ./cmd/compile/internal/ssa/gen/AMD64Ops.go
For NEGB we have asm: "NEGL"

вторник, 29 марта 2016 г., 21:04:43 UTC+3 пользователь Philip Hofer
написал:
The changes for amd64 were pretty simple:

1) Turn "cmp $0, %reg" into "test %reg, %reg", since it is one byte
shorter
2) Eliminate "test %reg, %reg" where %reg was produced with an
arithmetic instruction that would have set the flags
3) Use 32- instead of 64-bit instructions in elimshortmov.

I'm gonna take a shot at converting the patches to the new SSA rulegen
format. Does this look like an accurate translation of (1)?

diff --git a/src/cmd/compile/internal/ssa/gen/AMD64.rules
b/src/cmd/compile/internal/ssa/gen/AMD64.rules
index bc932c9..061d716 100644
--- a/src/cmd/compile/internal/ssa/gen/AMD64.rules
+++ b/src/cmd/compile/internal/ssa/gen/AMD64.rules
@@ -1239,6 +1239,12 @@
(CMPWconst (ANDWconst [c] x) [0]) -> (TESTWconst [c] x)
(CMPBconst (ANDBconst [c] x) [0]) -> (TESTBconst [c] x)

+// TEST %reg,%reg is shorter than CMP
+(CMPQconst x [0]) -> (TESTQ x x)
+(CMPLconst x [0]) -> (TESTL x x)
+(CMPWconst x [0]) -> (TESTW x x)
+(CMPBconst x [0]) -> (TESTB x x)
+

On Tue, Mar 29, 2016 at 10:39 AM, Keith Randall wrote:

The plan is to retire peep.go (and cgen.go, ...) for each architecture
as the SSA backend becomes the default.
So I don't think it is worth upstreaming them. Maybe the arm stuff for
1.7 if they are significant wins.

I'd be interested to see your changes to amd64 so I can make sure the
SSA backend performs an equivalent optimization.

On Tue, Mar 29, 2016 at 10:21 AM, Philip Hofer <pho...@umich.edu>
wrote:
I have a couple small patches to peep.go for arm and amd64 sitting on
my box locally. I'm happy to send them upstream if the plan is to keep the
existing peephole optimizer around for a while, but IIRC there were some
bigger plans for that code. Is that still (or was it ever) the case?

--
You received this message because you are subscribed to the Google
Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 14 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 29, '16 at 5:21p
activeApr 1, '16 at 3:14p
posts14
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase