An error occurred fetching the project authors.
- 11 Feb, 2015 1 commit
-
-
Russ Cox authored
This isn't everything, but it's a start. Still producing bit-identical compiler output. The semantics of the old back ends is preserved, even when they are probably buggy. There are some TODOs in gc/gsubr.c to remove special cases to preserve bugs in 5g and 8g. Change-Id: I28ae295fbfc94ef9df43e13ab96bd6fc2f194bc4 Reviewed-on: https://go-review.googlesource.com/3802Reviewed-by:
Austin Clements <austin@google.com>
-
- 03 Feb, 2015 1 commit
-
-
Russ Cox authored
Change-Id: I3417a8c5ddd7f405939edc9fdef086e4741495a1 Reviewed-on: https://go-review.googlesource.com/3571Reviewed-by:
Austin Clements <austin@google.com>
-
- 30 Jan, 2015 1 commit
-
-
Russ Cox authored
Change-Id: I19ed283962aa0221cf806307bde9ea0773a1bfd4 Reviewed-on: https://go-review.googlesource.com/3518Reviewed-by:
Austin Clements <austin@google.com>
-
- 26 Jan, 2015 1 commit
-
-
Russ Cox authored
- Change forward reference to struct Node* to void* in liblink. - Use explicit (Node*) casts in cmd/gc to get at that field. - Define struct Array in go.h instead of hiding it in array.c. - Remove some sizeof(uint32), sizeof(uint64) uses. - Remove some ? : expressions. - Rewrite some problematic mid-expression assignments. Change-Id: I308c70140238a0cfffd90e133f86f442cd0e17d4 Reviewed-on: https://go-review.googlesource.com/3276Reviewed-by:
Rob Pike <r@golang.org>
-
- 23 Dec, 2014 1 commit
-
-
Keith Randall authored
Calls to goproc/deferproc used to push & pop two extra arguments, the argument size and the function to call. Now, we allocate space for those arguments in the outargs section so we don't have to modify the SP. Defers now use the stack pointer (instead of the argument pointer) to identify which frame they are associated with. A followon CL might simplify funcspdelta and some of the stack walking code. Fixes issue #8641 Change-Id: I835ec2f42f0392c5dec7cb0fe6bba6f2aed1dad8 Reviewed-on: https://go-review.googlesource.com/1601Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 15 Oct, 2014 1 commit
-
-
Russ Cox authored
Among other things, *x = T{} does not need a write barrier. The changes here avoid an unnecessary copy even when no pointers are involved, so it may have larger effects. In 6g and 8g, avoid manually repeated STOSQ in favor of writing explicit MOVs, under the theory that the MOVs should have fewer dependencies and pipeline better. Benchmarks compare best of 5 on a 2012 MacBook Pro Core i5 with TurboBoost disabled. Most improvements can be explained by the changes in this CL. The effect in Revcomp is real but harder to explain: none of the instructions in the inner loop changed. I suspect loop alignment but really have no idea. benchmark old new delta BenchmarkBinaryTree17 3809027371 3819907076 +0.29% BenchmarkFannkuch11 3607547556 3686983012 +2.20% BenchmarkFmtFprintfEmpty 118 103 -12.71% BenchmarkFmtFprintfString 289 277 -4.15% BenchmarkFmtFprintfInt 304 290 -4.61% BenchmarkFmtFprintfIntInt 507 458 -9.66% BenchmarkFmtFprintfPrefixedInt 425 408 -4.00% BenchmarkFmtFprintfFloat 555 555 +0.00% BenchmarkFmtManyArgs 1835 1733 -5.56% BenchmarkGobDecode 14738209 14639331 -0.67% BenchmarkGobEncode 14239039 13703571 -3.76% BenchmarkGzip 538211054 538701315 +0.09% BenchmarkGunzip 135430877 134818459 -0.45% BenchmarkHTTPClientServer 116488 116618 +0.11% BenchmarkJSONEncode 28923406 29294334 +1.28% BenchmarkJSONDecode 105779820 104289543 -1.41% BenchmarkMandelbrot200 5791758 5771964 -0.34% BenchmarkGoParse 5376642 5310943 -1.22% BenchmarkRegexpMatchEasy0_32 195 190 -2.56% BenchmarkRegexpMatchEasy0_1K 477 455 -4.61% BenchmarkRegexpMatchEasy1_32 170 165 -2.94% BenchmarkRegexpMatchEasy1_1K 1410 1394 -1.13% BenchmarkRegexpMatchMedium_32 336 329 -2.08% BenchmarkRegexpMatchMedium_1K 108979 106328 -2.43% BenchmarkRegexpMatchHard_32 5854 5821 -0.56% BenchmarkRegexpMatchHard_1K 185089 182838 -1.22% BenchmarkRevcomp 834920364 780202624 -6.55% BenchmarkTemplate 137046937 129728756 -5.34% BenchmarkTimeParse 600 594 -1.00% BenchmarkTimeFormat 559 539 -3.58% LGTM=r R=r CC=golang-codereviews, iant, khr, rlh https://golang.org/cl/157910047
-
- 12 Sep, 2014 2 commits
-
-
Robert Griesemer authored
http://build.golang.org/log/0434a945e3351eedaf56aa824d2bfe9c0d5e6735 LGTM=dave R=bradfitz, dave CC=golang-codereviews https://golang.org/cl/144800043
-
Russ Cox authored
The argsize PCDATA was specifying the number of bytes passed to a function call, so that if the function did not specify its argument count, the garbage collector could use the call site information to scan those bytes conservatively. We don't do that anymore, so stop generating the information. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/139530043
-
- 08 Sep, 2014 1 commit
-
-
Russ Cox authored
This CL adjusts code referring to src/pkg to refer to src. Immediately after submitting this CL, I will submit a change doing 'hg mv src/pkg/* src'. That change will be too large to review with Rietveld but will contain only the 'hg mv'. This CL will break the build. The followup 'hg mv' will fix it. For more about the move, see golang.org/s/go14nopkg. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/134570043
-
- 11 Aug, 2014 1 commit
-
-
Russ Cox authored
Credit to Rémy for finding and writing test case. Fixes #8325. LGTM=r R=golang-codereviews, r CC=dave, golang-codereviews, iant, remyoudompheng https://golang.org/cl/124950043
-
- 04 Apr, 2014 1 commit
-
-
Rémy Oudompheng authored
Native Client forbids jumps/calls to arbitrary locations and enforces a particular alignement, which makes the Duff's device ineffective. LGTM=khr R=rsc, dave, khr CC=golang-codereviews https://golang.org/cl/84400043
-
- 02 Apr, 2014 5 commits
-
-
David du Colombier authored
warning: src/cmd/8g/ggen.c:35 non-interruptable temporary warning: src/cmd/gc/walk.c:656 set and not used: l warning: src/cmd/gc/walk.c:658 set and not used: l LGTM=minux.ma R=golang-codereviews, minux.ma CC=golang-codereviews https://golang.org/cl/83660043
-
Keith Randall authored
Don't merge with the zero range, we may end up zeroing more than we need. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/83430044
-
Keith Randall authored
Use Duff's device for zeroing. Combine adjacent regions. Update #7680 Update #7624 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/83200045
-
Russ Cox authored
Botched during CL 83090046. TBR=khr CC=golang-codereviews https://golang.org/cl/83070046
-
Russ Cox authored
1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
-
- 01 Apr, 2014 2 commits
-
-
Keith Randall authored
REP MOVSQ and REP STOSQ have a really high startup overhead. Use a Duff's device to do the repetition instead. benchmark old ns/op new ns/op delta BenchmarkClearFat32 7.20 1.60 -77.78% BenchmarkCopyFat32 6.88 2.38 -65.41% BenchmarkClearFat64 7.15 3.20 -55.24% BenchmarkCopyFat64 6.88 3.44 -50.00% BenchmarkClearFat128 9.53 5.34 -43.97% BenchmarkCopyFat128 9.27 5.56 -40.02% BenchmarkClearFat256 13.8 9.53 -30.94% BenchmarkCopyFat256 13.5 10.3 -23.70% BenchmarkClearFat512 22.3 18.0 -19.28% BenchmarkCopyFat512 22.0 19.7 -10.45% BenchmarkCopyFat1024 36.5 38.4 +5.21% BenchmarkClearFat1024 35.1 35.0 -0.28% TODO: use for stack frame zeroing TODO: REP prefixes are still used for "reverse" copying when src/dst regions overlap. Might be worth fixing. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews, r https://golang.org/cl/81370046
-
Russ Cox authored
The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
-
- 27 Mar, 2014 1 commit
-
-
Russ Cox authored
1. On entry to a function, only zero the ambiguously live stack variables. Before, we were zeroing all stack variables containing pointers. The zeroing is pretty inefficient right now (issue 7624), but there are also too many stack variables detected as ambiguously live (issue 7345), and that must be addressed before deciding how to improve the zeroing code. (Changes in 5g/ggen.c, 6g/ggen.c, 8g/ggen.c, gc/pgen.c) Fixes #7647. 2. Make the regopt word-based liveness analysis preserve the whole-variable liveness property expected by the garbage collection bitmap liveness analysis. That is, if the regopt liveness decides that one word in a struct needs to be preserved, make sure it preserves the entire struct. This is particularly important for multiword values such as strings, slices, and interfaces, in which all the words need to be present in order to understand the meaning. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c.) Fixes #7591. 3. Make the regopt word-based liveness analysis treat a variable as having its address taken - which makes it preserved across all future calls - whenever n->addrtaken is set, for consistency with the gc bitmap liveness analysis, even if there is no machine instruction actually taking the address. In this case n->addrtaken is incorrect (a nicer way to put it is overconservative), and ideally there would be no such cases, but they can happen and the two analyses need to agree. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c; test in bug484.go.) Fixes crashes found by turning off "zero everything" in step 1. 4. Remove spurious VARDEF annotations. As the comment in gc/pgen.c explains, the VARDEF must immediately precede the initialization. It cannot be too early, and it cannot be too late. In particular, if a function call sits between the VARDEF and the actual machine instructions doing the initialization, the variable will be treated as live during that function call even though it is uninitialized, leading to problems. (Changes in gc/gen.c; test in live.go.) Fixes crashes found by turning off "zero everything" in step 1. 5. Do not treat loading the address of a wide value as a signal that the value must be initialized. Instead depend on the existence of a VARDEF or the first actual read/write of a word in the value. If the load is in order to pass the address to a function that does the actual initialization, treating the load as an implicit VARDEF causes the same problems as described in step 4. The alternative is to arrange to zero every such value before passing it to the real initialization function, but this is a much easier and more efficient change. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 6. Treat wide input parameters with their address taken as initialized on entry to the function. Otherwise they look "ambiguously live" and we will try to emit code to zero them. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 7. An array of length 0 has no pointers, even if the element type does. Without this change, the zeroing code complains when asked to clear a 0-length array. (Changes in gc/reflect.c.) LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80160044
-
- 19 Mar, 2014 1 commit
-
-
Keith Randall authored
Removes most uses of the REP prefix, which has a high startup cost. LGTM=iant R=golang-codereviews, iant, khr CC=golang-codereviews https://golang.org/cl/77920043
-
- 25 Feb, 2014 2 commits
-
-
Josh Bleecher Snyder authored
maxstksize is superfluous and appears to be vestigial. 6g does not use it. c >= 4 cannot occur; c = w % 4. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/68750043
-
Dave Cheney authored
See golang.org/s/go13nacl for design overview. This CL is the mostly mechanical changes from rsc's Go 1.2 based NaCl branch, specifically 39cb35750369 to 500771b477cf from https://code.google.com/r/rsc-go13nacl. This CL does not include working NaCl support, there are probably two or three more large merges to come. CL 15750044 is not included as it involves more invasive changes to the linker which will need to be merged separately. The exact change lists included are 15050047: syscall: support for Native Client 15360044: syscall: unzip implementation for Native Client 15370044: syscall: Native Client SRPC implementation 15400047: cmd/dist, cmd/go, go/build, test: support for Native Client 15410048: runtime: support for Native Client 15410049: syscall: file descriptor table for Native Client 15410050: syscall: in-memory file system for Native Client 15440048: all: update +build lines for Native Client port 15540045: cmd/6g, cmd/8g, cmd/gc: support for Native Client 15570045: os: support for Native Client 15680044: crypto/..., hash/crc32, reflect, sync/atomic: support for amd64p32 15690044: net: support for Native Client 15690048: runtime: support for fake time like on Go Playground 15690051: build: disable various tests on Native Client LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/68150047
-
- 19 Feb, 2014 1 commit
-
-
Russ Cox authored
The code here is being restored after its deletion in CL 14430048. I restored the copy in cmd/6g in CL 56430043 but neglected the other two. This is the reason that enabling precisestack only worked on amd64. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/66170043
-
- 15 Feb, 2014 1 commit
-
-
Russ Cox authored
The VARDEF placement must be before the initialization but after any final use. If you have something like s = ... using s ... the rhs must be evaluated, then the VARDEF, then the lhs assigned. There is a large comment in pgen.c on gvardef explaining this in more detail. This CL also includes Ian's suggestions from earlier CLs, namely commenting the use of mode in link.h and fixing the precedence of the ~r check in dcl.c. This CL enables the check that if liveness analysis decides a variable is live on entry to the function, that variable must be a function parameter (not a result, and not a local variable). If this check fails, it indicates a bug in the liveness analysis or in the generated code being analyzed. The race detector generates invalid code for append(x, y...). The code declares a temporary t and then uses cap(t) before initializing t. The new liveness check catches this bug and stops the compiler from writing out the buggy code. Consequently, this CL disables the race detector tests in run.bash until the race detector bug can be fixed (golang.org/issue/7334). Except for the race detector bug, the liveness analysis check does not detect any problems (this CL and the previous CLs fixed all the detected problems). The net test still fails with GOGC=0 but the rest of the tests now pass or time out (because GOGC=0 is so slow). TBR=iant CC=golang-codereviews https://golang.org/cl/64170043
-
- 14 Feb, 2014 2 commits
-
-
Russ Cox authored
The test added in CL 63630043 fails on 5g and 8g because they were not emitting the VARDEF instruction when clearing a fat value by clearing the components. 6g had the call in the right place. Hooray tests. TBR=iant CC=golang-codereviews https://golang.org/cl/63660043
-
Russ Cox authored
The "fat" referred to being used for multiword values only. We're going to use it for non-fat values sometimes too. No change other than the renaming. TBR=iant CC=golang-codereviews https://golang.org/cl/63650043
-
- 12 Feb, 2014 1 commit
-
-
Anthony Martin authored
We now use the %A, %D, %P, and %R routines from liblink across the board. Fixes #7178. Fixes #7055. LGTM=iant R=golang-codereviews, gobot, rsc, dave, iant, remyoudompheng CC=golang-codereviews https://golang.org/cl/49170043
-
- 09 Dec, 2013 1 commit
-
-
Russ Cox authored
Preparation for golang.org/s/go13linker work. This CL does not build by itself. It depends on 35740044 and 35790044 and will be submitted at the same time. R=iant CC=golang-dev https://golang.org/cl/34590045
-
- 06 Dec, 2013 1 commit
-
-
Carl Shapiro authored
cmd/5g, cmd/5l, cmd/6g, cmd/6l, cmd/8g, cmd/8l, cmd/gc, runtime: generate pointer maps by liveness analysis This change allows the garbage collector to examine stack slots that are determined as live and containing a pointer value by the garbage collector. This results in a mean reduction of 65% in the number of stack slots scanned during an invocation of "GOGC=1 all.bash". Unfortunately, this does not yet allow garbage collection to be precise for the stack slots computed as live. Pointers confound the determination of what definitions reach a given instruction. In general, this problem is not solvable without runtime cost but some advanced cooperation from the compiler might mitigate common cases. R=golang-dev, rsc, cshapiro CC=golang-dev https://golang.org/cl/14430048
-
- 17 Sep, 2013 1 commit
-
-
Russ Cox authored
This eliminates ~75% of the nil checks being emitted, on all architectures. We can do better, but we need a bit more general support from the compiler, and I don't want to do that so close to Go 1.2. What's here is simple but effective and safe. A few small code generation cleanups were required to make the analysis consistent on all systems about which nil checks are omitted, at least in the test. Fixes #6019. R=ken2 CC=golang-dev https://golang.org/cl/13334052
-
- 06 Sep, 2013 1 commit
-
-
Russ Cox authored
Lucio De Re reports that the more complex loop miscompiles on Plan 9. R=ken2 CC=golang-dev https://golang.org/cl/13602043
-
- 17 Aug, 2013 1 commit
-
-
Russ Cox authored
When the new call site-specific frame bitmaps are available, we can cut the zeroing to just those values that need it due to scope escaping. R=cshapiro, cshapiro CC=golang-dev https://golang.org/cl/13045043
-
- 16 Aug, 2013 1 commit
-
-
Carl Shapiro authored
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12740046
-
- 15 Aug, 2013 1 commit
-
-
Russ Cox authored
See golang.org/s/go12nil. This CL is about getting all the right checks inserted. A followup CL will add an optimization pass to remove redundant checks. R=ken2 CC=golang-dev https://golang.org/cl/12970043
-
- 10 Aug, 2013 1 commit
-
-
Russ Cox authored
On entry to a function, zero the results and zero the pointer section of the local variables. This is an intermediate step on the way to precise collection of Go frames. This can incur a significant (up to 30%) slowdown, but it also ensures that the garbage collector never looks at a word in a Go frame and sees a stale pointer value that could cause a space leak. (C frames and assembly frames are still possibly problematic.) This CL is required to start making collection of interface values as precise as collection of pointer values are today. Since we have to dereference the interface type to understand whether the value is a pointer, it is critical that the type field be initialized. A future CL by Carl will make the garbage collection pointer bitmaps context-sensitive. At that point it will be possible to remove most of the zeroing. The only values that will still need zeroing are values whose addresses escape the block scoping of the function but do not escape to the heap. benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 4420289180 4331060459 -2.02% BenchmarkFannkuch11 3442469663 3277706251 -4.79% BenchmarkFmtFprintfEmpty 100 142 +42.00% BenchmarkFmtFprintfString 262 310 +18.32% BenchmarkFmtFprintfInt 213 281 +31.92% BenchmarkFmtFprintfIntInt 355 431 +21.41% BenchmarkFmtFprintfPrefixedInt 321 383 +19.31% BenchmarkFmtFprintfFloat 444 533 +20.05% BenchmarkFmtManyArgs 1380 1559 +12.97% BenchmarkGobDecode 10240054 11794915 +15.18% BenchmarkGobEncode 17350274 19970478 +15.10% BenchmarkGzip 455179460 460699139 +1.21% BenchmarkGunzip 114271814 119291574 +4.39% BenchmarkHTTPClientServer 89051 89894 +0.95% BenchmarkJSONEncode 40486799 52691558 +30.15% BenchmarkJSONDecode 94193361 112428781 +19.36% BenchmarkMandelbrot200 4747060 4748043 +0.02% BenchmarkGoParse 6363798 6675098 +4.89% BenchmarkRegexpMatchEasy0_32 129 171 +32.56% BenchmarkRegexpMatchEasy0_1K 365 395 +8.22% BenchmarkRegexpMatchEasy1_32 106 152 +43.40% BenchmarkRegexpMatchEasy1_1K 952 1245 +30.78% BenchmarkRegexpMatchMedium_32 198 283 +42.93% BenchmarkRegexpMatchMedium_1K 79006 101097 +27.96% BenchmarkRegexpMatchHard_32 3478 5115 +47.07% BenchmarkRegexpMatchHard_1K 110245 163582 +48.38% BenchmarkRevcomp 777384355 793270857 +2.04% BenchmarkTemplate 136713089 157093609 +14.91% BenchmarkTimeParse 1511 1761 +16.55% BenchmarkTimeFormat 535 850 +58.88% benchmark old MB/s new MB/s speedup BenchmarkGobDecode 74.95 65.07 0.87x BenchmarkGobEncode 44.24 38.43 0.87x BenchmarkGzip 42.63 42.12 0.99x BenchmarkGunzip 169.81 162.67 0.96x BenchmarkJSONEncode 47.93 36.83 0.77x BenchmarkJSONDecode 20.60 17.26 0.84x BenchmarkGoParse 9.10 8.68 0.95x BenchmarkRegexpMatchEasy0_32 247.24 186.31 0.75x BenchmarkRegexpMatchEasy0_1K 2799.20 2591.93 0.93x BenchmarkRegexpMatchEasy1_32 299.31 210.44 0.70x BenchmarkRegexpMatchEasy1_1K 1074.71 822.45 0.77x BenchmarkRegexpMatchMedium_32 5.04 3.53 0.70x BenchmarkRegexpMatchMedium_1K 12.96 10.13 0.78x BenchmarkRegexpMatchHard_32 9.20 6.26 0.68x BenchmarkRegexpMatchHard_1K 9.29 6.26 0.67x BenchmarkRevcomp 326.95 320.40 0.98x BenchmarkTemplate 14.19 12.35 0.87x R=cshapiro CC=golang-dev https://golang.org/cl/12616045
-
- 31 Jul, 2013 1 commit
-
-
Dmitriy Vyukov authored
This is required to properly unwind reflect.methodValueCall/makeFuncStub. Fixes #5954. Stats for 'go install std': 61849 total INSTCALL 24655 currently have ArgSize metadata 27278 have ArgSize metadata with this change godoc size before: 11351888, after: 11364288 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/12163043
-
- 17 Jul, 2013 1 commit
-
-
Daniel Morsing authored
clearfat (used to zero initialize structures) will use AX for x86 block ops. If we write to AX while calculating the dest pointer, we will fill the structure with incorrect values. Since 64-bit arithmetic uses AX to synthesize a 64-bit register, getting an adress by indexing with 64-bit ops can clobber the register. Fixes #5820. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/11383043
-
- 16 Jul, 2013 1 commit
-
-
Russ Cox authored
If calling a function in package runtime, emit argument size information around the call in case the call is to a variadic C function. R=ken2 CC=golang-dev https://golang.org/cl/11371043
-
- 12 Jul, 2013 1 commit
-
-
Russ Cox authored
Deferred functions are not run by a call instruction. They are run by the runtime editing registers to make the call start with a caller PC returning to a CALL deferreturn instruction. That instruction has always had the line number of the function's closing brace, but that instruction's line number is irrelevant. Stack traces show the line number of the instruction before the return PC, because normally that's what started the call. Not so here. The instruction before the CALL deferreturn could be almost anywhere in the function; it's unrelated and its line number is incorrect to show. Fix the line number by inserting a true hardware no-op with the right line number before the returned-to CALL instruction. That is, the deferred calls now appear to start with a caller PC returning to the second instruction in this sequence: NOP CALL deferreturn The traceback will show the line number of the NOP, which we've set to be the line number of the function's closing brace. The NOP here is not the usual pseudo-instruction, which would be elided by the linker. Instead it is the real hardware instruction: XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM. Fixes #5856. R=ken2, ken CC=golang-dev https://golang.org/cl/11223043
-
- 28 Jun, 2013 1 commit
-
-
Russ Cox authored
Keeping the string "compactframe" because that's what I always search for to find this code. But point to the real place too. TBR=iant CC=golang-dev https://golang.org/cl/10676047
-