aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/ssa/addressingmodes.go
AgeCommit message (Collapse)Author
2020-10-27cmd/compile: clean up ValAndOff funcs after untyped aux removalAlberto Donizetti
Changes: - makeValAndOff is deleted in favour of MakeValAndOff{32,64} - canAdd is renamed to canAdd64 to uniform with existing canAdd32 - addOffset{32,64} is simplified by directly using MakeValAndOff{32,64} - ValAndOff.Int64 is removed Change-Id: Ic01db7fa31ddfe0aaaf1d1d77af823d48a7bee84 Reviewed-on: https://go-review.googlesource.com/c/go/+/265357 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Alberto Donizetti <alb.donizetti@gmail.com>
2020-08-27cmd/compile: use addressing modes pass on s390xMichael Munday
Add s390x support to the addressing modes pass. This significantly reduces the number of rules we need to have to handle indexed addressing modes on s390x. There are some changes introduced with the new approach. Notably pointer calculations of the form '(ADD x (ADDconst y [c]))' won't get fully merged into address fields right now, the constant offset will remain separate. That is a relatively minor issue though. file before after Δ % addr2line 4120904 4120960 +56 +0.001% api 4944005 4948765 +4760 +0.096% asm 4977431 4984335 +6904 +0.139% buildid 2683760 2683504 -256 -0.010% cgo 4557976 4558408 +432 +0.009% compile 19103577 18916634 -186943 -0.979% cover 4883694 4885054 +1360 +0.028% dist 3545177 3553689 +8512 +0.240% doc 3921766 3921518 -248 -0.006% fix 3295254 3302182 +6928 +0.210% link 6539222 6540286 +1064 +0.016% nm 4105085 4107757 +2672 +0.065% objdump 4546015 4545439 -576 -0.013% pack 2416661 2415485 -1176 -0.049% pprof 13267433 13265489 -1944 -0.015% test2json 2762180 2761996 -184 -0.007% trace 10145090 10135626 -9464 -0.093% vet 6772946 6771738 -1208 -0.018% total 106588176 106418865 -169311 -0.159% Fixes #37891. Change-Id: If60d51f31eb2806b011432a6519951b8668cb42f Reviewed-on: https://go-review.googlesource.com/c/go/+/250958 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-07-27cmd/compile: add floating point load+op operations to addressing modes passKeith Randall
They were missed as part of the refactoring to use a separate addressing modes pass. Fixes #40426 Change-Id: Ie0418b2fac4ba1ffe720644ac918f6d728d5e420 Reviewed-on: https://go-review.googlesource.com/c/go/+/244859 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-04-30cmd/compile: add indexed memory modification ops to amd64Keith Randall
name old time/op new time/op delta Modify-16 404ns ± 1% 365ns ± 1% -9.73% (p=0.000 n=10+10) ConstModify-16 407ns ± 0% 385ns ± 2% -5.56% (p=0.000 n=9+10) Seems to generally help generated code. Binary size change is in the noise. Change-Id: I57891bfaf0f7dfc5d143bb9f7ebafc7079d2614f Reviewed-on: https://go-review.googlesource.com/c/go/+/228098 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2020-04-30cmd/compile: add indexed load+op operations to amd64Keith Randall
name old time/op new time/op delta LoadAdd-16 545ns ± 0% 456ns ± 0% -16.31% (p=0.000 n=10+10) Update #36468 Change-Id: I84f390d55490648fa1f58cdbc24fd74c4f1bc8c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/227960 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2020-04-15cmd/compile: split up the addressing mode on OpAMD64CMP*loadidx* alwaysDavid Chase
Benchmarking suggests that the combo instruction is notably slower, at least in the places where we measure. Updates #37955 Change-Id: I829f1975dd6edf38163128ba51d84604055512f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/228157 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2020-04-01cmd/compile: add indexed-load CMP instructionsKeith Randall
Things like CMPQ 4(AX)(BX*8), CX Fixes #37955 Change-Id: Icbed430f65c91a0e3f38a633d8321d79433ad8b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/224219 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2020-03-27cmd/compile: convert 386 port to use addressing modes pass (take 2)Keith Randall
Retrying CL 222782, with a fix that will hopefully stop the random crashing. The issue with the previous CL is that it does pointer arithmetic in a way that may briefly generate an out-of-bounds pointer. If an interrupt happens to occur in that state, the referenced object may be collected incorrectly. Suppose there was code that did s[x+c]. The previous CL had a rule to the effect of ptr + (x + c) -> c + (ptr + x). But ptr+x is not guaranteed to point to the same object as ptr. In contrast, ptr+(x+c) is guaranteed to point to the same object as ptr, because we would have already checked that x+c is in bounds. For example, strconv.trim used to have this code: MOVZX -0x1(BX)(DX*1), BP CMPL $0x30, AL After CL 222782, it had this code: LEAL 0(BX)(DX*1), BP CMPB $0x30, -0x1(BP) An interrupt between those last two instructions could see BP pointing outside the backing store of the slice involved. It's really hard to actually demonstrate a bug. First, you need to have an interrupt occur at exactly the right time. Then, there must be no other pointers to the object in question. Since the interrupted frame will be scanned conservatively, there can't even be a dead pointer in another register or on the stack. (In the example above, a bug can't happen because BX still holds the original pointer.) Then, the object in question needs to be collected (or at least scanned?) before the interrupted code continues. This CL needs to handle load combining somewhat differently than CL 222782 because of the new restriction on arithmetic. That's the only real difference (other than removing the bad rules) from that old CL. This bug is also present in the amd64 rewrite rules, and we haven't seen any crashing as a result. I will fix up that code similarly to this one in a separate CL. Update #37881 Change-Id: I5f0d584d9bef4696bfe89a61ef0a27c8d507329f Reviewed-on: https://go-review.googlesource.com/c/go/+/225798 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-03-24Revert "cmd/compile: convert 386 port to use addressing modes pass"Keith Randall
This reverts commit CL 222782. Reason for revert: Reverting to see if 386 errors go away Update #37881 Change-Id: I74f287404c52414db1b6ff1649effa4ed9e5cc0c Reviewed-on: https://go-review.googlesource.com/c/go/+/225218 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-03-24Revert "cmd/compile: disable mem+op operations on 386"Keith Randall
This reverts commit CL 224837. Reason for revert: Reverting partial reverts of 222782. Update #37881 Change-Id: Ie9bf84d6e17ed214abe538965e5ff03936886826 Reviewed-on: https://go-review.googlesource.com/c/go/+/225217 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-03-24Revert "cmd/compile: disable addressingmodes pass for 386"Keith Randall
This reverts commit CL 225057. Reason for revert: Undoing partial reverts of CL 222782 Update #37881 Change-Id: Iee024cab2a580a37a0fc355e0e3c5ad3d8fdaf7d Reviewed-on: https://go-review.googlesource.com/c/go/+/225197 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-03-23cmd/compile: disable addressingmodes pass for 386Keith Randall
Update #37881 Change-Id: I1f9a3f57f6215a19c31765c257ee78715eab36b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/225057 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-03-23cmd/compile: disable mem+op operations on 386Keith Randall
Rolling back portions of CL 222782 to see if that helps issue #37881 any. Update #37881 Change-Id: I9cc3ff8c469fa5e4b22daec715d04148033f46f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/224837 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-03-13cmd/compile: convert 386 port to use addressing modes passKeith Randall
Update #36468 Change-Id: Idfdb845d097994689be450d6e8a57fa9adb57166 Reviewed-on: https://go-review.googlesource.com/c/go/+/222782 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2020-03-10cmd/compile: insert complicated x86 addressing modes as a separate passKeith Randall
Use a separate compiler pass to introduce complicated x86 addressing modes. Loads in the normal architecture rules (for x86 and all other platforms) can have constant offsets (AuxInt values) and symbols (Aux values), but no more. The complex addressing modes (x+y, x+2*y, etc.) are introduced in a separate pass that combines loads with LEAQx ops. Organizing rewrites this way simplifies the number of rewrites required, as there are lots of different rule orderings that have to be specified to ensure these complex addressing modes are always found if they are possible. Update #36468 Change-Id: I5b4bf7b03a1e731d6dfeb9ef19b376175f3b4b44 Reviewed-on: https://go-review.googlesource.com/c/go/+/217097 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion