summaryrefslogtreecommitdiff
path: root/src/cmd/8g/gsubr.c
Commit message (Collapse)AuthorAgeFilesLines
* cmd/5g, cmd/8g: make 'out of registers' a fatal errorRuss Cox2014-09-161-1/+1
| | | | | | | | | | There's no point in continuing. We will only get confused. 6g already makes this fatal. LGTM=dave, minux, iant R=iant, dave, minux CC=golang-codereviews https://codereview.appspot.com/140660043
* cmd/cc, cmd/gc: stop generating 'argsize' PCDATARuss Cox2014-09-121-10/+0
| | | | | | | | | | | | | | 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://codereview.appspot.com/139530043
* build: adjustments for move from src/pkg to srcRuss Cox2014-09-081-2/+2
| | | | | | | | | | | | | | | | | | | 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://codereview.appspot.com/134570043
* cmd/gc, runtime: treat slices and strings like pointers in garbage collectionRuss Cox2014-08-251-1/+0
| | | | | | | | | | | | | | | | | | | Before, a slice with cap=0 or a string with len=0 might have its base pointer pointing beyond the actual slice/string data into the next block. The collector had to ignore slices and strings with cap=0 in order to avoid misinterpreting the base pointer. Now, a slice with cap=0 or a string with len=0 still has a base pointer pointing into the actual slice/string data, no matter what. The collector can now always scan the pointer, which means strings and slices are no longer special. Fixes issue 8404. LGTM=khr, josharian R=josharian, khr, dvyukov CC=golang-codereviews https://codereview.appspot.com/112570044
* cmd/gc: mark auxiliary symbols as containing no pointersDmitriy Vyukov2014-07-231-5/+2
| | | | | | | | | | | | They do not, but pretend that they do. The immediate need is that it breaks the new GC because these are weird symbols as if with pointers but not necessary pointer aligned. LGTM=rsc R=golang-codereviews, dave, josharian, khr, rsc CC=golang-codereviews, iant, khr, rlh https://codereview.appspot.com/116060043
* build: annotations and modifications for c2goRuss Cox2014-07-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | The main changes fall into a few patterns: 1. Replace #define with enum. 2. Add /*c2go */ comment giving effect of #define. This is necessary for function-like #defines and non-enum-able #defined constants. (Not all compilers handle negative or large enums.) 3. Add extra braces in struct initializer. (c2go does not implement the full rules.) This is enough to let c2go typecheck the source tree. There may be more changes once it is doing other semantic analyses. LGTM=minux, iant R=minux, dave, iant CC=golang-codereviews https://codereview.appspot.com/106860045
* cmd/gc: fix x=x crashRuss Cox2014-05-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Same as CL 102820043 except applied changes to 6g/gsubr.c also to 5g/gsubr.c and 8g/gsubr.c. The problem I had last night trying to do that was that 8g's copy of nodarg has different (but equivalent) control flow and I was pasting the new code into the wrong place.] Description from CL 102820043: The 'nodarg' function is used to obtain a Node* representing a function argument or result. It returned a brand new Node*, but that violates the guarantee in most places in the compiler that two Node*s refer to the same variable if and only if they are the same Node* pointer. Reestablish that invariant by making nodarg return a preexisting named variable if present. Having fixed that, avoid any copy during x=x in componentgen, because the VARDEF we emit before the copy marks the lhs x as dead incorrectly. The change in walk.c avoids modifying the result of nodarg. This was the only place in the compiler that did so. Fixes issue 8097. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, iant, khr, r https://codereview.appspot.com/103750043
* cmd/gc: alias more variables during register allocationJosh Bleecher Snyder2014-05-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is joint work with Daniel Morsing. In order for the register allocator to alias two variables, they must have the same width, stack offset, and etype. Code generation was altering a variable's etype in a few places. This prevented the variable from being moved to a register, which in turn prevented peephole optimization. This failure to alias was very common, with almost 23,000 instances just running make.bash. This phenomenon was not visible in the register allocation debug output because the variables that failed to alias had the same name. The debugging-only change to bits.c fixes this by printing the variable number with its name. This CL fixes the source of all etype mismatches for 6g, all but one case for 8g, and depressingly few cases for 5g. (I believe that extending CL 6819083 to 5g is a prerequisite.) Fixing the remaining cases in 8g and 5g is work for the future. The etype mismatch fixes are: * [gc] Slicing changed the type of the base pointer into a uintptr in order to perform arithmetic on it. Instead, support addition directly on pointers. * [*g] OSPTR was giving type uintptr to slice base pointers; undo that. This arose, for example, while compiling copy(dst, src). * [8g] 64 bit float conversion was assigning int64 type during codegen, overwriting the existing uint64 type. Note that some etype mismatches are appropriate, such as a struct with a single field or an array with a single element. With these fixes, the number of registerizations that occur while running make.bash for 6g increases ~10%. Hello world binary size shrinks ~1.5%. Running all benchmarks in the standard library show performance improvements ranging from nominal to substantive (>10%); a full comparison using 6g on my laptop is available at https://gist.github.com/josharian/8f9b5beb46667c272064. The microbenchmarks must be taken with a grain of salt; see issue 7920. The few benchmarks that show real regressions are likely due to issue 7920. I manually examined the generated code for the top few regressions and none had any assembly output changes. The few benchmarks that show extraordinary improvements are likely also due to issue 7920. Performance results from 8g appear similar to 6g. 5g shows no performance improvements. This is not surprising, given the discussion above. Update issue 7316 LGTM=rsc R=rsc, daniel.morsing, bradfitz CC=dave, golang-codereviews https://codereview.appspot.com/91850043 Committer: Russ Cox <rsc@golang.org>
* cmd/ld: clear unused ctxt before morestackRuss Cox2014-03-041-0/+2
| | | | | | | | | | | | | | | | | | For non-closure functions, the context register is uninitialized on entry and will not be used, but morestack saves it and then the garbage collector treats it as live. This can be a source of memory leaks if the context register points at otherwise dead memory. Avoid this by introducing a parallel set of morestack functions that clear the context register, and use those for the non-closure functions. I hope this will help with some of the finalizer flakiness, but it probably won't. Fixes issue 7244. LGTM=dvyukov R=khr, dvyukov CC=golang-codereviews https://codereview.appspot.com/71030044
* cmd/cc, cmd/gc, cmd/ld: consolidate print format routinesAnthony Martin2014-02-121-2/+2
| | | | | | | | | | | | | | | We now use the %A, %D, %P, and %R routines from liblink across the board. Fixes issue 7178. Fixes issue 7055. LGTM=iant R=golang-codereviews, gobot, rsc, dave, iant, remyoudompheng CC=golang-codereviews https://codereview.appspot.com/49170043 Committer: Russ Cox <rsc@golang.org>
* cmd/cc, cmd/gc: update compilers, assemblers for liblink changesRuss Cox2013-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | - add buffered stdout to all tools and provide to link ctxt. - avoid extra \n before ! in .6 files written by assemblers (makes them match the C compilers). - use linkwriteobj instead of linkouthist+linkwritefuncs. - in assemblers and C compilers, record pc explicitly in Prog, for use by liblink. - in C compilers, preserve jump target links. - in Go compilers (gsubr.c) attach gotype directly to corresponding LSym* instead of rederiving from instruction stream. - in Go compilers, emit just one definition for runtime.zerovalue from each compilation. This CL consists entirely of small adjustments. The heavy lifting is in CL 39680043. Each depends on the other. R=golang-dev, dave, iant CC=golang-dev https://codereview.appspot.com/37030045
* cmd/5g, cmd/6g, cmd/8g: use liblinkRuss Cox2013-12-081-26/+24
| | | | | | | | | | | 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://codereview.appspot.com/34590045
* cmd/gc: inline copy in frontend to call memmove directly.R?my Oudompheng2013-09-121-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new node type OSPTR is added to refer to the data pointer of strings and slices in a simple way during walk(). It will be useful for future work on simplification of slice arithmetic. benchmark old ns/op new ns/op delta BenchmarkCopy1Byte 9 8 -13.98% BenchmarkCopy2Byte 14 8 -40.49% BenchmarkCopy4Byte 13 8 -35.04% BenchmarkCopy8Byte 13 8 -37.10% BenchmarkCopy12Byte 14 12 -15.38% BenchmarkCopy16Byte 14 12 -17.24% BenchmarkCopy32Byte 19 14 -27.32% BenchmarkCopy128Byte 31 26 -15.29% BenchmarkCopy1024Byte 100 92 -7.50% BenchmarkCopy1String 10 7 -28.99% BenchmarkCopy2String 10 7 -28.06% BenchmarkCopy4String 10 8 -22.69% BenchmarkCopy8String 10 8 -23.30% BenchmarkCopy12String 11 11 -5.88% BenchmarkCopy16String 11 11 -5.08% BenchmarkCopy32String 15 14 -6.58% BenchmarkCopy128String 28 25 -10.60% BenchmarkCopy1024String 95 95 +0.53% R=golang-dev, bradfitz, cshapiro, dave, daniel.morsing, rsc, khr, khr CC=golang-dev https://codereview.appspot.com/9101048
* cmd/gc: &x panics if x doesRuss Cox2013-08-151-43/+0
| | | | | | | | | | | | 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://codereview.appspot.com/12970043
* cmd/5g, cmd/6g, cmd/8g: insert arg size annotations on runtime callsRuss Cox2013-07-161-0/+11
| | | | | | | | | 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://codereview.appspot.com/11371043
* runtime: record proper goroutine state during stack splitRuss Cox2013-06-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, the goroutine state has been scattered during the execution of newstack and oldstack. It's all there, and those routines know how to get back to a working goroutine, but other pieces of the system, like stack traces, do not. If something does interrupt the newstack or oldstack execution, the rest of the system can't understand the goroutine. For example, if newstack decides there is an overflow and calls throw, the stack tracer wouldn't dump the goroutine correctly. For newstack to save a useful state snapshot, it needs to be able to rewind the PC in the function that triggered the split back to the beginning of the function. (The PC is a few instructions in, just after the call to morestack.) To make that possible, we change the prologues to insert a jmp back to the beginning of the function after the call to morestack. That is, the prologue used to be roughly: TEXT myfunc check for split jmpcond nosplit call morestack nosplit: sub $xxx, sp Now an extra instruction is inserted after the call: TEXT myfunc start: check for split jmpcond nosplit call morestack jmp start nosplit: sub $xxx, sp The jmp is not executed directly. It is decoded and simulated by runtime.rewindmorestack to discover the beginning of the function, and then the call to morestack returns directly to the start label instead of to the jump instruction. So logically the jmp is still executed, just not by the cpu. The prologue thus repeats in the case of a function that needs a stack split, but against the cost of the split itself, the extra few instructions are noise. The repeated prologue has the nice effect of making a stack split double-check that the new stack is big enough: if morestack happens to return on a too-small stack, we'll now notice before corruption happens. The ability for newstack to rewind to the beginning of the function should help preemption too. If newstack decides that it was called for preemption instead of a stack split, it now has the goroutine state correctly paused if rescheduling is needed, and when the goroutine can run again, it can return to the start label on its original stack and re-execute the split check. Here is an example of a split stack overflow showing the full trace, without any special cases in the stack printer. (This one was triggered by making the split check incorrect.) runtime: newstack framesize=0x0 argsize=0x18 sp=0x6aebd0 stack=[0x6b0000, 0x6b0fa0] morebuf={pc:0x69f5b sp:0x6aebd8 lr:0x0} sched={pc:0x68880 sp:0x6aebd0 lr:0x0 ctxt:0x34e700} runtime: split stack overflow: 0x6aebd0 < 0x6b0000 fatal error: runtime: split stack overflow goroutine 1 [stack split]: runtime.mallocgc(0x290, 0x100000000, 0x1) /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:21 fp=0x6aebd8 runtime.new() /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:682 +0x5b fp=0x6aec08 go/build.(*Context).Import(0x5ae340, 0xc210030c71, 0xa, 0xc2100b4380, 0x1b, ...) /Users/rsc/g/go/src/pkg/go/build/build.go:424 +0x3a fp=0x6b00a0 main.loadImport(0xc210030c71, 0xa, 0xc2100b4380, 0x1b, 0xc2100b42c0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:249 +0x371 fp=0x6b01a8 main.(*Package).load(0xc21017c800, 0xc2100b42c0, 0xc2101828c0, 0x0, 0x0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:431 +0x2801 fp=0x6b0c98 main.loadPackage(0x369040, 0x7, 0xc2100b42c0, 0x0) /Users/rsc/g/go/src/cmd/go/pkg.go:709 +0x857 fp=0x6b0f80 ----- stack segment boundary ----- main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc2100e6c00, 0xc2100e5750, ...) /Users/rsc/g/go/src/cmd/go/build.go:539 +0x437 fp=0x6b14a0 main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc21015b400, 0x2, ...) /Users/rsc/g/go/src/cmd/go/build.go:528 +0x1d2 fp=0x6b1658 main.(*builder).test(0xc2100902a0, 0xc210092000, 0x0, 0x0, 0xc21008ff60, ...) /Users/rsc/g/go/src/cmd/go/test.go:622 +0x1b53 fp=0x6b1f68 ----- stack segment boundary ----- main.runTest(0x5a6b20, 0xc21000a020, 0x2, 0x2) /Users/rsc/g/go/src/cmd/go/test.go:366 +0xd09 fp=0x6a5cf0 main.main() /Users/rsc/g/go/src/cmd/go/main.go:161 +0x4f9 fp=0x6a5f78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:183 +0x92 fp=0x6a5fa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1266 fp=0x6a5fa8 And here is a seg fault during oldstack: SIGSEGV: segmentation violation PC=0x1b2a6 runtime.oldstack() /Users/rsc/g/go/src/pkg/runtime/stack.c:159 +0x76 runtime.lessstack() /Users/rsc/g/go/src/pkg/runtime/asm_amd64.s:270 +0x22 goroutine 1 [stack unsplit]: fmt.(*pp).printArg(0x2102e64e0, 0xe5c80, 0x2102c9220, 0x73, 0x0, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:818 +0x3d3 fp=0x221031e6f8 fmt.(*pp).doPrintf(0x2102e64e0, 0x12fb20, 0x2, 0x221031eb98, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:1183 +0x15cb fp=0x221031eaf0 fmt.Sprintf(0x12fb20, 0x2, 0x221031eb98, 0x1, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:234 +0x67 fp=0x221031eb40 flag.(*stringValue).String(0x2102c9210, 0x1, 0x0) /Users/rsc/g/go/src/pkg/flag/flag.go:180 +0xb3 fp=0x221031ebb0 flag.(*FlagSet).Var(0x2102f6000, 0x293d38, 0x2102c9210, 0x143490, 0xa, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:633 +0x40 fp=0x221031eca0 flag.(*FlagSet).StringVar(0x2102f6000, 0x2102c9210, 0x143490, 0xa, 0x12fa60, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:550 +0x91 fp=0x221031ece8 flag.(*FlagSet).String(0x2102f6000, 0x143490, 0xa, 0x12fa60, 0x0, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:563 +0x87 fp=0x221031ed38 flag.String(0x143490, 0xa, 0x12fa60, 0x0, 0x161950, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:570 +0x6b fp=0x221031ed80 testing.init() /Users/rsc/g/go/src/pkg/testing/testing.go:-531 +0xbb fp=0x221031edc0 strings_test.init() /Users/rsc/g/go/src/pkg/strings/strings_test.go:1115 +0x62 fp=0x221031ef70 main.init() strings/_test/_testmain.go:90 +0x3d fp=0x221031ef78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:180 +0x8a fp=0x221031efa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 fp=0x221031efa8 goroutine 2 [runnable]: runtime.MHeap_Scavenger() /Users/rsc/g/go/src/pkg/runtime/mheap.c:438 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 created by runtime.main /Users/rsc/g/go/src/pkg/runtime/proc.c:166 rax 0x23ccc0 rbx 0x23ccc0 rcx 0x0 rdx 0x38 rdi 0x2102c0170 rsi 0x221032cfe0 rbp 0x221032cfa0 rsp 0x7fff5fbff5b0 r8 0x2102c0120 r9 0x221032cfa0 r10 0x221032c000 r11 0x104ce8 r12 0xe5c80 r13 0x1be82baac718 r14 0x13091135f7d69200 r15 0x0 rip 0x1b2a6 rflags 0x10246 cs 0x2b fs 0x0 gs 0x0 Fixes issue 5723. R=r, dvyukov, go.peter.90, dave, iant CC=golang-dev https://codereview.appspot.com/10360048
* cmd/gc: fix some overflows in the compilerRob Pike2013-04-291-1/+2
| | | | | | | | | | Some 64-bit fields were run through 32-bit words, some counts were not checked for overflow, and relocations must fit in 32 bits. Tests to follow. R=golang-dev, dsymonds CC=golang-dev https://codereview.appspot.com/9033043
* cmd/gc: implement method valuesRuss Cox2013-03-201-11/+5
| | | | | | R=ken2, ken CC=golang-dev https://codereview.appspot.com/7546052
* cmd/gc: emit explicit type information for local variablesRuss Cox2013-02-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The type information is (and for years has been) included as an extra field in the address chunk of an instruction. Unfortunately, suppose there is a string at a+24(FP) and we have an instruction reading its length. It will say: MOVQ x+32(FP), AX and the type of *that* argument is int (not slice), because it is the length being read. This confuses the picture seen by debuggers and now, worse, by the garbage collector. Instead of attaching the type information to all uses, emit an explicit list of TYPE instructions with the information. The TYPE instructions are no-ops whose only role is to provide an address to attach type information to. For example, this function: func f(x, y, z int) (a, b string) { return } now compiles into: --- prog list "f" --- 0000 (/Users/rsc/x.go:3) TEXT f+0(SB),$0-56 0001 (/Users/rsc/x.go:3) LOCALS , 0002 (/Users/rsc/x.go:3) TYPE x+0(FP){int},$8 0003 (/Users/rsc/x.go:3) TYPE y+8(FP){int},$8 0004 (/Users/rsc/x.go:3) TYPE z+16(FP){int},$8 0005 (/Users/rsc/x.go:3) TYPE a+24(FP){string},$16 0006 (/Users/rsc/x.go:3) TYPE b+40(FP){string},$16 0007 (/Users/rsc/x.go:3) MOVQ $0,b+40(FP) 0008 (/Users/rsc/x.go:3) MOVQ $0,b+48(FP) 0009 (/Users/rsc/x.go:3) MOVQ $0,a+24(FP) 0010 (/Users/rsc/x.go:3) MOVQ $0,a+32(FP) 0011 (/Users/rsc/x.go:4) RET , The { } show the formerly hidden type information. The { } syntax is used when printing from within the gc compiler. It is not accepted by the assemblers. The same type information is now included on global variables: 0055 (/Users/rsc/x.go:15) GLOBL slice+0(SB){[]string},$24(AL*0) This more accurate type information fixes a bug in the garbage collector's precise heap collection. The linker only cares about globals right now, but having the local information should make things a little nicer for Carl in the future. Fixes issue 4907. R=ken2 CC=golang-dev https://codereview.appspot.com/7395056
* cmd/gc: avoid runtime code generation for closuresRuss Cox2013-02-221-0/+18
| | | | | | | | | | | | Change ARM context register to R7, to get out of the way of the register allocator during the compilation of the prologue statements (it wants to use R0 as a temporary). Step 2 of http://golang.org/s/go11func. R=ken2 CC=golang-dev https://codereview.appspot.com/7369048
* cmd/gc, reflect, runtime: switch to indirect func value representationRuss Cox2013-02-211-1/+3
| | | | | | | | Step 1 of http://golang.org/s/go11func. R=golang-dev, r, daniel.morsing, remyoudompheng CC=golang-dev https://codereview.appspot.com/7393045
* cmd/8g: add a few missing splitcleanRuss Cox2013-02-071-1/+1
| | | | | | | | Fixes issue 887. R=ken2 CC=golang-dev https://codereview.appspot.com/7303061
* cmd/8g, cmd/dist, cmd/gc: fix warnings on Plan 9Anthony Martin2013-01-181-4/+1
| | | | | | | | | | | | cmd/8g/gsubr.c: unreachable code cmd/8g/reg.c: overspecifed class cmd/dist/plan9.c: unused parameter cmd/gc/fmt.c: stkdelta is now a vlong cmd/gc/racewalk.c: used but not set R=golang-dev, seed, rsc CC=golang-dev https://codereview.appspot.com/7067052
* cmd/8g: fix possibly uninitialized variable in foptoas.R?my Oudompheng2013-01-021-0/+1
| | | | | | R=golang-dev, rsc CC=golang-dev https://codereview.appspot.com/7045043
* cmd/dist, cmd/8g: implement GO386=387/sse to choose FPU flavour.R?my Oudompheng2013-01-021-138/+492
| | | | | | | | | | | | | | | A new environment variable GO386 is introduced to choose between code generation targeting 387 or SSE2. No auto-detection is performed and the setting defaults to 387 to preserve previous behaviour. The patch is a reorganization of CL6549052 by rsc. Fixes issue 3912. R=minux.ma, rsc CC=golang-dev https://codereview.appspot.com/6962043
* undo CL 6938073 / 1542912cf09dRuss Cox2012-12-221-38/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove zerostack compiler experiment; will do at link time instead ??? original CL description cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entry This is expensive but it might be useful in cases where people are suffering from false positives during garbage collection and are willing to trade the CPU time for getting rid of the false positives. On the other hand it only eliminates false positives caused by other function calls, not false positives caused by dead temporaries stored in the current function call. The 5g/6g/8g changes were pulled out of the history, from the last time we needed to do this (to work around a goto bug). The code in go.h, lex.c, pgen.c is new but tiny. R=ken2 CC=golang-dev https://codereview.appspot.com/6938073 ??? R=ken2 CC=golang-dev https://codereview.appspot.com/7002051
* cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entryRuss Cox2012-12-171-0/+38
| | | | | | | | | | | | | | | | | | | This is expensive but it might be useful in cases where people are suffering from false positives during garbage collection and are willing to trade the CPU time for getting rid of the false positives. On the other hand it only eliminates false positives caused by other function calls, not false positives caused by dead temporaries stored in the current function call. The 5g/6g/8g changes were pulled out of the history, from the last time we needed to do this (to work around a goto bug). The code in go.h, lex.c, pgen.c is new but tiny. R=ken2 CC=golang-dev https://codereview.appspot.com/6938073
* cmd/{5,6,8}g: reduce size of Prog and AddrDave Cheney2012-12-141-5/+5
| | | | | | | | | | | | | | 5g: Prog went from 128 bytes to 88 bytes 6g: Prog went from 174 bytes to 144 bytes 8g: Prog went from 124 bytes to 92 bytes There may be a little more that can be squeezed out of Addr, but alignment will be a factor. All: remove the unused pun field from Addr R=rsc, minux.ma CC=golang-dev https://codereview.appspot.com/6922048
* cmd/gc: add division rewrite to walk pass.R?my Oudompheng2012-11-261-0/+16
| | | | | | | | | | | | This allows 5g and 8g to benefit from the rewrite as shifts or magic multiplies. The 64-bit arithmetic is not handled there, and left in 6g. Update issue 2230. R=golang-dev, dave, mtj, iant, rsc CC=golang-dev http://codereview.appspot.com/6819123
* cmd/8g: fix erroneous LEAL nil.R?my Oudompheng2012-11-211-1/+1
| | | | | | | | Fixes issue 4399. R=golang-dev, nigeltao CC=golang-dev http://codereview.appspot.com/6845053
* cmd/gc, cmd/ld: struct field trackingRuss Cox2012-11-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an experiment in static analysis of Go programs to understand which struct fields a program might use. It is not part of the Go language specification, it must be enabled explicitly when building the toolchain, and it may be removed at any time. After building the toolchain with GOEXPERIMENT=fieldtrack, a specific field can be marked for tracking by including `go:"track"` in the field tag: package pkg type T struct { F int `go:"track"` G int // untracked } To simplify usage, only named struct types can have tracked fields, and only exported fields can be tracked. The implementation works by making each function begin with a sequence of no-op USEFIELD instructions declaring which tracked fields are accessed by a specific function. After the linker's dead code elimination removes unused functions, the fields referred to by the remaining USEFIELD instructions are the ones reported as used by the binary. The -k option to the linker specifies the fully qualified symbol name (such as my/pkg.list) of a string variable that should be initialized with the field tracking information for the program. The field tracking string is a sequence of lines, each terminated by a \n and describing a single tracked field referred to by the program. Each line is made up of one or more tab-separated fields. The first field is the name of the tracked field, fully qualified, as in "my/pkg.T.F". Subsequent fields give a shortest path of reverse references from that field to a global variable or function, corresponding to one way in which the program might reach that field. A common source of false positives in field tracking is types with large method sets, because a reference to the type descriptor carries with it references to all methods. To address this problem, the CL also introduces a comment annotation //go:nointerface that marks an upcoming method declaration as unavailable for use in satisfying interfaces, both statically and dynamically. Such a method is also invisible to package reflect. Again, all of this is disabled by default. It only turns on if you have GOEXPERIMENT=fieldtrack set during make.bash. R=iant, ken CC=golang-dev http://codereview.appspot.com/6749064
* cmd/6g, cmd/8g: add OINDREG, ODOT, ODOTPTR cases to igen.R?my Oudompheng2012-09-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apart from reducing the number of LEAL/LEAQ instructions by about 30%, it gives 8g easier registerization in several cases, for example in strconv. Performance with 6g is not affected. Before (386): src/pkg/strconv/decimal.go:22 TEXT (*decimal).String+0(SB),$240-12 src/pkg/strconv/extfloat.go:540 TEXT (*extFloat).ShortestDecimal+0(SB),$584-20 After (386): src/pkg/strconv/decimal.go:22 TEXT (*decimal).String+0(SB),$196-12 src/pkg/strconv/extfloat.go:540 TEXT (*extFloat).ShortestDecimal+0(SB),$420-20 Benchmarks with GOARCH=386 (on a Core 2). benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 7110191000 7079644000 -0.43% BenchmarkFannkuch11 7769274000 7766514000 -0.04% BenchmarkGobDecode 33454820 34755400 +3.89% BenchmarkGobEncode 11675710 11007050 -5.73% BenchmarkGzip 2013519000 1593855000 -20.84% BenchmarkGunzip 253368200 242667600 -4.22% BenchmarkJSONEncode 152443900 120763400 -20.78% BenchmarkJSONDecode 304112800 247461800 -18.63% BenchmarkMandelbrot200 29245520 29240490 -0.02% BenchmarkParse 8484105 8088660 -4.66% BenchmarkRevcomp 2695688000 2841263000 +5.40% BenchmarkTemplate 363759800 277271200 -23.78% benchmark old ns/op new ns/op delta BenchmarkAtof64Decimal 127 129 +1.57% BenchmarkAtof64Float 166 164 -1.20% BenchmarkAtof64FloatExp 308 300 -2.60% BenchmarkAtof64Big 584 571 -2.23% BenchmarkAppendFloatDecimal 440 430 -2.27% BenchmarkAppendFloat 995 776 -22.01% BenchmarkAppendFloatExp 897 746 -16.83% BenchmarkAppendFloatNegExp 900 752 -16.44% BenchmarkAppendFloatBig 1528 1228 -19.63% BenchmarkAppendFloat32Integer 443 453 +2.26% BenchmarkAppendFloat32ExactFraction 812 661 -18.60% BenchmarkAppendFloat32Point 1002 773 -22.85% BenchmarkAppendFloat32Exp 858 725 -15.50% BenchmarkAppendFloat32NegExp 848 728 -14.15% BenchmarkAppendFloat64Fixed1 447 431 -3.58% BenchmarkAppendFloat64Fixed2 480 462 -3.75% BenchmarkAppendFloat64Fixed3 461 457 -0.87% BenchmarkAppendFloat64Fixed4 509 484 -4.91% Update issue 1914. R=rsc, nigeltao CC=golang-dev, remy http://codereview.appspot.com/6494107
* cmd/gc: fix use of nil interface, sliceRuss Cox2012-09-221-0/+6
| | | | | | | | Fixes issue 3670. R=ken2 CC=golang-dev http://codereview.appspot.com/6542058
* cmd/6g, cmd/8g: eliminate short integer arithmetic when possible.R?my Oudompheng2012-09-011-1/+2
| | | | | | | | | Fixes issue 3909. Fixes issue 3910. R=rsc, nigeltao CC=golang-dev http://codereview.appspot.com/6442114
* cmd/8g: fix miscompilation due to BADWIDTH.R?my Oudompheng2012-08-031-0/+1
| | | | | | | | Fixes issue 3899. R=rsc CC=golang-dev, remy http://codereview.appspot.com/6453084
* cmd/gc: cache itab lookup in convT2I.Nigel Tao2012-07-031-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There may be further savings if convT2I can avoid the function call if the cache is good and T is uintptr-shaped, a la convT2E, but that will be a follow-up CL. src/pkg/runtime: benchmark old ns/op new ns/op delta BenchmarkConvT2ISmall 43 15 -64.01% BenchmarkConvT2IUintptr 45 14 -67.48% BenchmarkConvT2ILarge 130 101 -22.31% test/bench/go1: benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 8588997000 8499058000 -1.05% BenchmarkFannkuch11 5300392000 5358093000 +1.09% BenchmarkGobDecode 30295580 31040190 +2.46% BenchmarkGobEncode 18102070 17675650 -2.36% BenchmarkGzip 774191400 771591400 -0.34% BenchmarkGunzip 245915100 247464100 +0.63% BenchmarkJSONEncode 123577000 121423050 -1.74% BenchmarkJSONDecode 451969800 596256200 +31.92% BenchmarkMandelbrot200 10060050 10072880 +0.13% BenchmarkParse 10989840 11037710 +0.44% BenchmarkRevcomp 1782666000 1716864000 -3.69% BenchmarkTemplate 798286600 723234400 -9.40% R=rsc, bradfitz, go.peter.90, daniel.morsing, dave, uriel CC=golang-dev http://codereview.appspot.com/6337058
* cmd/gc: inline slice[arr,str] in the frontend (mostly).Luuk van Dijk2012-06-021-0/+19
| | | | | | | | R=rsc, ality, rogpeppe, minux.ma, dave CC=golang-dev http://codereview.appspot.com/5966075 Committer: Russ Cox <rsc@golang.org>
* cmd/5g, cmd/6g, cmd/8g: delete clearstkRuss Cox2012-06-011-38/+0
| | | | | | | | Dreg from http://codereview.appspot.com/4629042 R=ken2 CC=golang-dev http://codereview.appspot.com/6259057
* cmd/gc: contiguous loop layoutRuss Cox2012-05-301-22/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop expecttaken function in favor of extra argument to gbranch and bgen. Mark loop condition as likely to be true, so that loops are generated inline. The main benefit here is contiguous code when trying to read the generated assembly. It has only minor effects on the timing, and they mostly cancel the minor effects that aligning function entry points had. One exception: both changes made Fannkuch faster. Compared to before CL 6244066 (before aligned functions) benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 4222117400 4201958800 -0.48% BenchmarkFannkuch11 3462631800 3215908600 -7.13% BenchmarkGobDecode 20887622 20899164 +0.06% BenchmarkGobEncode 9548772 9439083 -1.15% BenchmarkGzip 151687 152060 +0.25% BenchmarkGunzip 8742 8711 -0.35% BenchmarkJSONEncode 62730560 62686700 -0.07% BenchmarkJSONDecode 252569180 252368960 -0.08% BenchmarkMandelbrot200 5267599 5252531 -0.29% BenchmarkRevcomp25M 980813500 985248400 +0.45% BenchmarkTemplate 361259100 357414680 -1.06% Compared to tip (aligned functions): benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 4140739800 4201958800 +1.48% BenchmarkFannkuch11 3259914400 3215908600 -1.35% BenchmarkGobDecode 20620222 20899164 +1.35% BenchmarkGobEncode 9384886 9439083 +0.58% BenchmarkGzip 150333 152060 +1.15% BenchmarkGunzip 8741 8711 -0.34% BenchmarkJSONEncode 65210990 62686700 -3.87% BenchmarkJSONDecode 249394860 252368960 +1.19% BenchmarkMandelbrot200 5273394 5252531 -0.40% BenchmarkRevcomp25M 996013800 985248400 -1.08% BenchmarkTemplate 360620840 357414680 -0.89% R=ken2 CC=golang-dev http://codereview.appspot.com/6245069
* cmd/6g, cmd/8g: move panicindex calls out of lineRuss Cox2012-05-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code generated for a bounds check was CMP JLT ok CALL panicindex ok: ... The new code is (once the linker finishes with it): CMP JGE panic ... panic: CALL panicindex which moves the calls out of line, putting more useful code in each cache line. This matters especially in tight loops, such as in Fannkuch. The benefit is more modest elsewhere, but real. From test/bench/go1, amd64: benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 6096092000 6088808000 -0.12% BenchmarkFannkuch11 6151404000 4020463000 -34.64% BenchmarkGobDecode 28990050 28894630 -0.33% BenchmarkGobEncode 12406310 12136730 -2.17% BenchmarkGzip 179923 179903 -0.01% BenchmarkGunzip 11219 11130 -0.79% BenchmarkJSONEncode 86429350 86515900 +0.10% BenchmarkJSONDecode 334593800 315728400 -5.64% BenchmarkRevcomp25M 1219763000 1180767000 -3.20% BenchmarkTemplate 492947600 483646800 -1.89% And 386: benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 6354902000 6243000000 -1.76% BenchmarkFannkuch11 8043769000 7326965000 -8.91% BenchmarkGobDecode 19010800 18941230 -0.37% BenchmarkGobEncode 14077500 13792460 -2.02% BenchmarkGzip 194087 193619 -0.24% BenchmarkGunzip 12495 12457 -0.30% BenchmarkJSONEncode 125636400 125451400 -0.15% BenchmarkJSONDecode 696648600 685032800 -1.67% BenchmarkRevcomp25M 2058088000 2052545000 -0.27% BenchmarkTemplate 602140000 589876800 -2.04% To implement this, two new instruction forms: JLT target // same as always JLT $0, target // branch expected not taken JLT $1, target // branch expected taken The linker could also emit the prediction prefixes, but it does not: expected taken branches are reversed so that the expected case is not taken (as in example above), and the default expectaton for such a jump is not taken already. R=golang-dev, gri, r, dave CC=golang-dev http://codereview.appspot.com/6248049
* cmd/gc: faster code, mainly for rotateRuss Cox2012-05-241-0/+16
| | | | | | | | | | * Eliminate bounds check on known small shifts. * Rewrite x<<s | x>>(32-s) as a rotate (constant s). * More aggressive (but still minimal) range analysis. R=ken, dave, iant CC=golang-dev http://codereview.appspot.com/6209077
* gc, ld: tag data as no-pointers and allocate in separate sectionRuss Cox2012-02-191-0/+2
| | | | | | | | | | The garbage collector can avoid scanning this section, with reduces collection time as well as the number of false positives. Helps a little bit with issue 909, but certainly does not solve it. R=ken2 CC=golang-dev http://codereview.appspot.com/5671099
* 5c, 6c, 8c, 6g, 8g: correct boundary checkingShenghou Ma2012-02-151-1/+1
| | | | | | | | | | CL 5666043 fixed the same checking for 5g. R=golang-dev, rsc CC=golang-dev http://codereview.appspot.com/5666045 Committer: Russ Cox <rsc@golang.org>
* gc: optimize interface ==, !=Russ Cox2012-02-111-0/+12
| | | | | | | | | | | | | | | | | If the values being compared have different concrete types, then they're clearly unequal without needing to invoke the actual interface compare routine. This speeds tests for specific values, like if err == io.EOF, by about 3x. benchmark old ns/op new ns/op delta BenchmarkIfaceCmp100 843 287 -65.95% BenchmarkIfaceCmpNil100 184 182 -1.09% Fixes issue 2591. R=ken2 CC=golang-dev http://codereview.appspot.com/5651073
* 8g: use uintptr for local pcRuss Cox2012-01-301-2/+2
| | | | | | | | Fixes issue 2478. R=ken2 CC=golang-dev http://codereview.appspot.com/5593051
* gc: fix another blank bugRuss Cox2011-12-091-0/+6
| | | | | | R=ken2 CC=golang-dev http://codereview.appspot.com/5478051
* gc: implement character constant type rulesRuss Cox2011-12-081-0/+1
| | | | | | R=ken2 CC=golang-dev http://codereview.appspot.com/5444054
* 5g, 6g, 8g: registerize variables againRuss Cox2011-10-031-2/+6
| | | | | | | | | | | | | | | | | | | | | My previous CL: changeset: 9645:ce2e5f44b310 user: Russ Cox <rsc@golang.org> date: Tue Sep 06 10:24:21 2011 -0400 summary: gc: unify stack frame layout introduced a bug wherein no variables were being registerized, making Go programs 2-3x slower than they had been before. This CL fixes that bug (along with some others it was hiding) and adds a test that optimization makes at least one test case faster. R=ken2 CC=golang-dev http://codereview.appspot.com/5174045
* gc: unify stack frame layoutRuss Cox2011-09-061-1/+0
| | | | | | | | | | | | | | | | | | allocparams + tempname + compactframe all knew about how to place stack variables. Now only compactframe, renamed to allocauto, does the work. Until the last minute, each PAUTO variable is in its own space and has xoffset == 0. This might break 5g. I get failures in concurrent code running under qemu and I can't tell whether it's 5g's fault or qemu's. We'll see what the real ARM builders say. R=ken2 CC=golang-dev http://codereview.appspot.com/4973057
* gc: make static initialization more staticRuss Cox2011-08-311-5/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | Does as much as possible in data layout instead of during the init function. Handles var x = y; var y = z as a special case too, because it is so prevalent in package unicode (var Greek = _Greek; var _Greek = []...). Introduces InitPlan description of initialized data so that it can be traversed multiple times (for example, in the copy handler). Cuts package unicode's init function size by 8x. All that remains there is map initialization, which is on the chopping block too. Fixes sinit.go test case. Aggregate DATA instructions at end of object file. Checkpoint. More to come. R=ken2 CC=golang-dev http://codereview.appspot.com/4969051
View Lorry Controller Status