An error occurred fetching the project authors.
  1. 16 Dec, 2013 1 commit
    • Russ Cox's avatar
      cmd/cc, cmd/gc: update compilers, assemblers for liblink changes · 870e821d
      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
      870e821d
  2. 09 Dec, 2013 1 commit
  3. 11 Sep, 2013 1 commit
    • Rémy Oudompheng's avatar
      cmd/gc: inline copy in frontend to call memmove directly. · ff416a3f
      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
      ff416a3f
  4. 15 Aug, 2013 1 commit
  5. 09 Aug, 2013 1 commit
    • Rémy Oudompheng's avatar
      cmd/5c, cmd/5g, cmd/5l: turn MOVB, MOVH into plain moves, optimize short arithmetic. · 357f7336
      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
      357f7336
  6. 08 Aug, 2013 1 commit
  7. 16 Jul, 2013 1 commit
  8. 27 Jun, 2013 1 commit
    • Russ Cox's avatar
      runtime: record proper goroutine state during stack split · 6fa3c89b
      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
      6fa3c89b
  9. 09 Jun, 2013 1 commit
  10. 30 Apr, 2013 1 commit
  11. 20 Mar, 2013 1 commit
  12. 25 Feb, 2013 2 commits
    • Shenghou Ma's avatar
      libmach, cmd/5a, cmd/5c, cmd/5g, cmd/5l: enable DWARF type info for Linux/ARM · 8cdee790
      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
      8cdee790
    • Russ Cox's avatar
      cmd/gc: emit explicit type information for local variables · 1d5dc4fd
      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
      1d5dc4fd
  13. 22 Feb, 2013 1 commit
  14. 21 Feb, 2013 1 commit
  15. 08 Feb, 2013 1 commit
  16. 22 Dec, 2012 1 commit
    • Russ Cox's avatar
      undo CL 6938073 / 1542912cf09d · e431398e
      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
      e431398e
  17. 17 Dec, 2012 1 commit
    • Russ Cox's avatar
      cmd/gc: add GOEXPERIMENT=zerostack to clear stack on function entry · b7603cfc
      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
      b7603cfc
  18. 13 Dec, 2012 1 commit
    • Dave Cheney's avatar
      cmd/{5,6,8}g: reduce size of Prog and Addr · b2797f2a
      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
      b2797f2a
  19. 12 Dec, 2012 1 commit
    • Dave Cheney's avatar
      cmd/5g: avoid temporary during OMINUS · 5bdf40dc
      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
      5bdf40dc
  20. 06 Dec, 2012 1 commit
  21. 27 Nov, 2012 1 commit
  22. 12 Nov, 2012 1 commit
  23. 02 Nov, 2012 2 commits
    • Rémy Oudompheng's avatar
      cmd/5g, cmd/6g: fix out of registers with array indexing. · 0b2353ed
      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
      0b2353ed
    • Russ Cox's avatar
      cmd/gc, cmd/ld: struct field tracking · 3d40062c
      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
      3d40062c
  24. 28 Oct, 2012 1 commit
  25. 07 Oct, 2012 1 commit
    • Dave Cheney's avatar
      cmd/5g: avoid temporary in slice bounds check · 01ddc8bd
      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
      01ddc8bd
  26. 22 Sep, 2012 1 commit
    • Russ Cox's avatar
      cmd/5g: fix register opt bug · 658482d7
      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
      658482d7
  27. 02 Jul, 2012 1 commit
    • Nigel Tao's avatar
      cmd/gc: cache itab lookup in convT2I. · 18e86644
      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
      18e86644
  28. 03 Jun, 2012 2 commits
  29. 01 Jun, 2012 1 commit
  30. 30 May, 2012 1 commit
    • Russ Cox's avatar
      cmd/gc: contiguous loop layout · 001b75c9
      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
      001b75c9
  31. 24 May, 2012 1 commit
  32. 22 Feb, 2012 2 commits
    • Russ Cox's avatar
      5c, 5g, 5l: fix arm bug · a5bc16d6
      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
      a5bc16d6
    • Russ Cox's avatar
      ld: add NOPTRBSS for large, pointer-free uninitialized data · 5bcad92f
      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
      5bcad92f
  33. 19 Feb, 2012 2 commits
  34. 14 Feb, 2012 1 commit
  35. 11 Feb, 2012 1 commit
    • Russ Cox's avatar
      gc: optimize interface ==, != · f91cc3bd
      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
      f91cc3bd