An error occurred fetching the project authors.
- 16 Dec, 2013 1 commit
-
-
Russ Cox authored
- 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://golang.org/cl/37030045
-
- 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
-
- 11 Sep, 2013 1 commit
-
-
Rémy Oudompheng authored
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://golang.org/cl/9101048
-
- 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
-
- 09 Aug, 2013 1 commit
-
-
Rémy Oudompheng authored
Pseudo-instructions MOVBS and MOVHS are used to clarify the semantics of short integers vs. registers: * 8-bit and 16-bit values in registers are assumed to always be zero-extended or sign-extended depending on their type. * MOVB is truncation or move of an already extended value between registers. * MOVBU enforces zero-extension at the destination (register). * MOVBS enforces sign-extension at the destination (register). And similarly for MOVH/MOVS/MOVHU. The linker is adapted to assemble MOVB and MOVH to an ordinary mov. Also a peephole pass in 5g that aims at eliminating redundant zero/sign extensions is improved. encoding/binary: benchmark old ns/op new ns/op delta BenchmarkReadSlice1000Int32s 220387 217185 -1.45% BenchmarkReadStruct 12839 12910 +0.55% BenchmarkReadInts 5692 5534 -2.78% BenchmarkWriteInts 6137 6016 -1.97% BenchmarkPutUvarint32 257 241 -6.23% BenchmarkPutUvarint64 812 754 -7.14% benchmark old MB/s new MB/s speedup BenchmarkReadSlice1000Int32s 18.15 18.42 1.01x BenchmarkReadStruct 5.45 5.42 0.99x BenchmarkReadInts 5.27 5.42 1.03x BenchmarkWriteInts 4.89 4.99 1.02x BenchmarkPutUvarint32 15.56 16.57 1.06x BenchmarkPutUvarint64 9.85 10.60 1.08x crypto/des: benchmark old ns/op new ns/op delta BenchmarkEncrypt 7002 5169 -26.18% BenchmarkDecrypt 7015 5195 -25.94% benchmark old MB/s new MB/s speedup BenchmarkEncrypt 1.14 1.55 1.36x BenchmarkDecrypt 1.14 1.54 1.35x strconv: benchmark old ns/op new ns/op delta BenchmarkAtof64Decimal 457 385 -15.75% BenchmarkAtof64Float 574 479 -16.55% BenchmarkAtof64FloatExp 1035 906 -12.46% BenchmarkAtof64Big 1793 1457 -18.74% BenchmarkAtof64RandomBits 2267 2066 -8.87% BenchmarkAtof64RandomFloats 1416 1194 -15.68% BenchmarkAtof32Decimal 451 379 -15.96% BenchmarkAtof32Float 547 435 -20.48% BenchmarkAtof32FloatExp 1095 986 -9.95% BenchmarkAtof32Random 1154 1006 -12.82% BenchmarkAtoi 1415 1380 -2.47% BenchmarkAtoiNeg 1414 1401 -0.92% BenchmarkAtoi64 1744 1671 -4.19% BenchmarkAtoi64Neg 1737 1662 -4.32% Fixes #1837. R=rsc, dave, bradfitz CC=golang-dev https://golang.org/cl/12424043
-
- 08 Aug, 2013 1 commit
-
-
Rémy Oudompheng authored
MOVBS and MOVHS are defined as duplicates of MOVB and MOVH, and perform sign-extension moving. No change is made to code generation. Update #1837 R=rsc, bradfitz CC=golang-dev https://golang.org/cl/12682043
-
- 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
-
- 27 Jun, 2013 1 commit
-
-
Russ Cox authored
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 #5723. R=r, dvyukov, go.peter.90, dave, iant CC=golang-dev https://golang.org/cl/10360048
-
- 09 Jun, 2013 1 commit
-
-
Shenghou Ma authored
R=golang-dev, bradfitz, khr, r CC=golang-dev https://golang.org/cl/7461046
-
- 30 Apr, 2013 1 commit
-
-
Rob Pike authored
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://golang.org/cl/9033043
-
- 20 Mar, 2013 1 commit
-
-
Russ Cox authored
R=ken2, ken CC=golang-dev https://golang.org/cl/7546052
-
- 25 Feb, 2013 2 commits
-
-
Shenghou Ma authored
Fixes #3747. Update #4912 This CL adds gotype into .5 object file. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7376054
-
Russ Cox authored
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 #4907. R=ken2 CC=golang-dev https://golang.org/cl/7395056
-
- 22 Feb, 2013 1 commit
-
-
Russ Cox authored
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://golang.org/cl/7369048
-
- 21 Feb, 2013 1 commit
-
-
Russ Cox authored
Step 1 of http://golang.org/s/go11func. R=golang-dev, r, daniel.morsing, remyoudompheng CC=golang-dev https://golang.org/cl/7393045
-
- 08 Feb, 2013 1 commit
-
-
Rémy Oudompheng authored
See issue 887 for the 8g analogue. R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/7306069
-
- 22 Dec, 2012 1 commit
-
-
Russ Cox authored
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://golang.org/cl/6938073 »»» R=ken2 CC=golang-dev https://golang.org/cl/7002051
-
- 17 Dec, 2012 1 commit
-
-
Russ Cox authored
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://golang.org/cl/6938073
-
- 13 Dec, 2012 1 commit
-
-
Dave Cheney authored
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://golang.org/cl/6922048
-
- 12 Dec, 2012 1 commit
-
-
Dave Cheney authored
Saves one MOVW and one register during the fast div/mod introduced in CL 6819123. linux/arm (armv5) benchmark old ns/op new ns/op delta BenchmarkInt64Mod1 12 12 +7.50% BenchmarkUint16Mod2 7 7 +0.28% BenchmarkUint16Mod4 7 7 -0.28% BenchmarkUint64Mod1 15 11 -23.72% BenchmarkInt8Neg 8 7 -17.66% BenchmarkInt16Neg 8 7 -17.66% BenchmarkInt32Neg 5 5 -9.04% BenchmarkUint8Neg 7 6 -14.35% BenchmarkUint16Neg 8 7 -17.66% BenchmarkUint32Neg 5 5 -9.04% R=rsc CC=golang-dev https://golang.org/cl/6842045
-
- 06 Dec, 2012 1 commit
-
-
Dave Cheney authored
Add missing file that should have been included in CL 6854063 / 5eac1a2d6fc3 R=remyoudompheng, minux.ma, rsc CC=golang-dev https://golang.org/cl/6891049
-
- 27 Nov, 2012 1 commit
-
-
Rémy Oudompheng authored
Fixes #4448. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/6855100
-
- 12 Nov, 2012 1 commit
-
-
Rémy Oudompheng authored
The patch adds more cases to agenr to allocate registers later, and makes 6g generate addresses for sgen in something else than SI and DI. It avoids a complex save/restore sequence that amounts to allocate a register before descending in subtrees. Fixes #4207. R=golang-dev, dave, rsc CC=golang-dev https://golang.org/cl/6817080
-
- 02 Nov, 2012 2 commits
-
-
Rémy Oudompheng authored
Compiling expressions like: s[s[s[s[s[s[s[s[s[s[s[s[i]]]]]]]]]]]] make 5g and 6g run out of registers. Such expressions can arise if a slice is used to represent a permutation and the user wants to iterate it. This is due to the usual problem of allocating registers before going down the expression tree, instead of allocating them in a postfix way. The functions cgenr and agenr (that generate a value to a newly allocated register instead of an existing location), are either introduced or modified when they already existed to allocate the new register as late as possible, and sudoaddable is disabled for OINDEX nodes so that igen/agenr is used instead. Update #4207. R=dave, daniel.morsing, rsc CC=golang-dev https://golang.org/cl/6733055
-
Russ Cox authored
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 https://golang.org/cl/6749064
-
- 28 Oct, 2012 1 commit
-
-
Rémy Oudompheng authored
It is essentially identical to the version in 6g. R=dave, minux.ma, rsc CC=golang-dev https://golang.org/cl/6710043
-
- 07 Oct, 2012 1 commit
-
-
Dave Cheney authored
before func addr(s[]int) *int { return &s[2] 10c1c: e28d0008 add r0, sp, #8 10c20: e5901004 ldr r1, [r0, #4] 10c24: e3a02002 mov r2, #2 10c28: e1510002 cmp r1, r2 10c2c: 8a000000 bhi 10c34 <main.addr+0x34> 10c30: eb0035e6 bl 1e3d0 <runtime.panicindex> 10c34: e5900000 ldr r0, [r0] 10c38: e2800008 add r0, r0, #8 10c3c: e58d0014 str r0, [sp, #20] 10c40: e49df004 pop {pc} ; (ldr pc, [sp], #4) after func addr(s[]int) *int { return &s[2] 10c1c: e28d0008 add r0, sp, #8 10c20: e5901004 ldr r1, [r0, #4] 10c24: e3510002 cmp r1, #2 10c28: 8a000000 bhi 10c30 <main.addr+0x30> 10c2c: eb0035e6 bl 1e3cc <runtime.panicindex> 10c30: e5900000 ldr r0, [r0] 10c34: e2800008 add r0, r0, #8 10c38: e58d0014 str r0, [sp, #20] 10c3c: e49df004 pop {pc} ; (ldr pc, [sp], #4) Also, relax gcmp restriction that 2nd operand must be a register. A followup CL will address the remaining TODO items. R=rsc, remyoudompheng, minux.ma CC=golang-dev https://golang.org/cl/6620064
-
- 22 Sep, 2012 1 commit
-
-
Russ Cox authored
The width was not being set on the address, which meant that the optimizer could not find variables that overlapped with it and mark them as having had their address taken. This let to the compiler believing variables had been set but never used and then optimizing away the set. Fixes #4129. R=ken2 CC=golang-dev https://golang.org/cl/6552059
-
- 02 Jul, 2012 1 commit
-
-
Nigel Tao authored
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 https://golang.org/cl/6337058
-
- 03 Jun, 2012 2 commits
-
-
Russ Cox authored
TBR=lvd CC=golang-dev https://golang.org/cl/6275048
-
Luuk van Dijk authored
R=rsc, ality, rogpeppe, minux.ma, dave CC=golang-dev https://golang.org/cl/5966075
-
- 01 Jun, 2012 1 commit
-
-
Russ Cox authored
Dreg from https://golang.org/cl/4629042 R=ken2 CC=golang-dev https://golang.org/cl/6259057
-
- 30 May, 2012 1 commit
-
-
Russ Cox authored
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 https://golang.org/cl/6245069
-
- 24 May, 2012 1 commit
-
-
Russ Cox authored
* 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 https://golang.org/cl/6209077
-
- 22 Feb, 2012 2 commits
-
-
Russ Cox authored
Using reg as the flag word was unfortunate, since the default value is not 0 but NREG (==16), which happens to be the bit NOPTR now. Clear it. If I say this will fix the build, it won't. R=golang-dev, r CC=golang-dev https://golang.org/cl/5690072
-
Russ Cox authored
cc: add #pragma textflag to set it runtime: mark mheap to go into noptr-bss. remove special case in garbage collector Remove the ARM from.flag field created by CL 5687044. The DUPOK flag was already in p->reg, so keep using that. Otherwise test/nilptr.go creates a very large binary. Should fix the arm build. Diagnosed by minux.ma; replacement for CL 5690044. R=golang-dev, minux.ma, r CC=golang-dev https://golang.org/cl/5686060
-
- 19 Feb, 2012 2 commits
-
-
Shenghou Ma authored
ARM doesn't have the concept of scale, so I renamed the field Addr.scale to Addr.flag to better reflect its true meaning. R=rsc CC=golang-dev https://golang.org/cl/5687044
-
Russ Cox authored
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 https://golang.org/cl/5671099
-
- 14 Feb, 2012 1 commit
-
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/5666043
-
- 11 Feb, 2012 1 commit
-
-
Russ Cox authored
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 #2591. R=ken2 CC=golang-dev https://golang.org/cl/5651073
-