1. 28 Apr, 2017 25 commits
  2. 27 Apr, 2017 15 commits
    • Josh Bleecher Snyder's avatar
      cmd/compile: minor writebarrier cleanup · 12c286c1
      Josh Bleecher Snyder authored
      This CL mainly moves some work to the switch on w.Op,
      to make a follow-up change simpler and clearer.
      
      Updates #19838
      
      Change-Id: I86f3181c380dd60960afcc24224f655276b8956c
      Reviewed-on: https://go-review.googlesource.com/42010
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      12c286c1
    • Josh Bleecher Snyder's avatar
      cmd/compile: move Used from gc.Node to gc.Name · fc08a19c
      Josh Bleecher Snyder authored
      Node.Used was written to from the backend
      concurrently with reads of Node.Class
      for the same ONAME Nodes.
      I do not know why it was not failing consistently
      under the race detector, but it is a race.
      
      This is likely also a problem with Node.HasVal and Node.HasOpt.
      They will be handled in a separate CL.
      
      Fix Used by moving it to gc.Name and making it a separate bool.
      There was one non-Name use of Used, marking OLABELs as used.
      That is no longer needed, now that goto and label checking
      happens early in the front end.
      
      Leave the getters and setters in place,
      to ease changing the representation in the future
      (or changing to an interface!).
      
      Updates #20144
      
      Change-Id: I9bec7c6d33dcb129a4cfa9d338462ea33087f9f7
      Reviewed-on: https://go-review.googlesource.com/42015
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      fc08a19c
    • Josh Bleecher Snyder's avatar
      cmd/compile: add Type.MustSize and Type.MustAlignment · 94d540a4
      Josh Bleecher Snyder authored
      Type.Size and Type.Alignment are for the front end:
      They calculate size and alignment if needed.
      
      Type.MustSize and Type.MustAlignment are for the back end:
      They call Fatal if size and alignment are not already calculated.
      
      Most uses are of MustSize and MustAlignment,
      but that's because the back end is newer,
      and this API was added to support it.
      
      This CL was mostly generated with sed and selective reversion.
      The only mildly interesting bit is the change of the ssa.Type interface
      and the supporting ssa dummy types.
      
      Follow-up to review feedback on CL 41970.
      
      Passes toolstash-check.
      
      Change-Id: I0d9b9505e57453dae8fb6a236a07a7a02abd459e
      Reviewed-on: https://go-review.googlesource.com/42016
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      94d540a4
    • Josh Bleecher Snyder's avatar
      cmd/compile: dowidth more in the front end · 0b6a10ef
      Josh Bleecher Snyder authored
      dowidth is fundamentally unsafe to call from the back end;
      it will cause data races.
      
      Replace all calls to dowidth in the backend with
      assertions that the width has been calculated.
      
      Then fix all the cases in which that was not so,
      including the cases from #20145.
      
      Fixes #20145.
      
      Change-Id: Idba3d19d75638851a30ec2ebcdb703c19da3e92b
      Reviewed-on: https://go-review.googlesource.com/41970
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      0b6a10ef
    • Michael Hudson-Doyle's avatar
      cmd/internal/objabi, cmd/link: move linker-only symkind values into linker · be2ee2a4
      Michael Hudson-Doyle authored
      Many (most!) of the values of objapi.SymKind are used only in the linker, so
      this creates a separate cmd/link/internal/ld.SymKind type, removes most values
      from SymKind and maps one to the other when reading object files in the linker.
      
      Two of the remaining objapi.SymKind values are only checked for, never set and
      so will never be actually found but I wanted to keep this to the most
      mechanical change possible.
      
      Change-Id: I4bbc5aed6713cab3e8de732e6e288eb77be0474c
      Reviewed-on: https://go-review.googlesource.com/40985
      Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      be2ee2a4
    • Hana Kim's avatar
      dwarf: add marker for embedded fields in dwarf · b1868cf1
      Hana Kim authored
      Currently, the following two codes generate the identical dwarf info
      for type Foo.
      
      prog 1)
      type Foo struct {
         Bar
      }
      
      prog 2)
      type Foo struct {
         Bar Bar
      }
      
      This change adds a go-specific attribute DW_AT_go_embedded_field
      to annotate each member entry. Its absence or false value indicates
      the corresponding member is not an embedded field.
      
      Update #20037
      
      Change-Id: Ibcbd2714f3e4d97c7b523d7398f29ab2301cc897
      Reviewed-on: https://go-review.googlesource.com/41873Reviewed-by: default avatarDavid Chase <drchase@google.com>
      b1868cf1
    • Josh Bleecher Snyder's avatar
      cmd/compile: randomize compilation order when race-enabled · f5c878e0
      Josh Bleecher Snyder authored
      There's been one failure on the race builder so far,
      before we started sorting functions by length.
      
      The race detector can only detect actual races,
      and ordering functions by length might reduce the odds
      of catching some kinds of races. Give it more to chew on.
      
      Updates #20144
      
      Change-Id: I0206ac182cb98b70a729dea9703ecb0fef54d2d0
      Reviewed-on: https://go-review.googlesource.com/41973
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      f5c878e0
    • Josh Bleecher Snyder's avatar
      cmd/compile: move nodarg to walk.go · 26e126d6
      Josh Bleecher Snyder authored
      Its sole use is in walk.go. 100% code movement.
      
      gsubr.go increasingly contains backend-y things.
      With a few more relocations, it could probably be
      fruitfully renamed progs.go.
      
      Change-Id: I61ec5c2bc1f8cfdda64c6d6f580952c154ff60e0
      Reviewed-on: https://go-review.googlesource.com/41972
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      26e126d6
    • Josh Bleecher Snyder's avatar
      cmd/compile: move addrescapes and moveToHeap to esc.go · fcee3777
      Josh Bleecher Snyder authored
      They were used only in esc.go. 100% code movement.
      
      Also, remove the rather outdated comment at the top of gen.go.
      It's not really clear what gen.go is for any more.
      
      Change-Id: Iaedfe7015ef6f5c11c49f3e6721b15d779a00faa
      Reviewed-on: https://go-review.googlesource.com/41971
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      fcee3777
    • Keith Randall's avatar
      cmd/internal/obj: ARM, use immediates instead of constant pool entries · 14f3ca56
      Keith Randall authored
      When a constant doesn't fit in a single instruction, use two
      paired instructions instead of the constant pool.  For example
      
        ADD $0xaa00bb, R0, R1
      
      Used to rewrite to:
      
        MOV ?(IP), R11
        ADD R11, R0, R1
      
      Instead, do:
      
        ADD $0xaa0000, R0, R1
        ADD $0xbb, R1, R1
      
      Same number of instructions.
      Good:
        4 less bytes (no constant pool entry)
        One less load.
      Bad:
        Critical path is one instruction longer.
      
      It's probably worth it to avoid the loads, they are expensive.
      
      Dave Cheney got us some performance numbers: https://perf.golang.org/search?q=upload:20170426.1
      TL;DR mean 1.37% improvement.
      
      Change-Id: Ib206836161fdc94a3962db6f9caa635c87d57cf1
      Reviewed-on: https://go-review.googlesource.com/41612
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      14f3ca56
    • Bryan C. Mills's avatar
      encoding/gob: replace RWMutex usage with sync.Map · c120e449
      Bryan C. Mills authored
      This provides a significant speedup for encoding and decoding when
      using many CPU cores.
      
      name                        old time/op  new time/op  delta
      EndToEndPipe                5.26µs ± 2%  5.38µs ± 7%     ~     (p=0.121 n=8+7)
      EndToEndPipe-6              1.86µs ± 5%  1.80µs ±11%     ~     (p=0.442 n=8+8)
      EndToEndPipe-48             1.39µs ± 2%  1.41µs ± 4%     ~     (p=0.645 n=8+8)
      EndToEndByteBuffer          1.54µs ± 5%  1.57µs ± 5%     ~     (p=0.130 n=8+8)
      EndToEndByteBuffer-6         620ns ± 6%   310ns ± 8%  -50.04%  (p=0.000 n=8+8)
      EndToEndByteBuffer-48        506ns ± 4%   110ns ± 3%  -78.22%  (p=0.000 n=8+8)
      EndToEndSliceByteBuffer      149µs ± 3%   153µs ± 5%   +2.80%  (p=0.021 n=8+8)
      EndToEndSliceByteBuffer-6    103µs ±17%    31µs ±12%  -70.06%  (p=0.000 n=8+8)
      EndToEndSliceByteBuffer-48  93.2µs ± 2%  18.0µs ± 5%  -80.66%  (p=0.000 n=7+8)
      EncodeComplex128Slice       20.6µs ± 5%  20.9µs ± 8%     ~     (p=0.959 n=8+8)
      EncodeComplex128Slice-6     4.10µs ±10%  3.75µs ± 8%   -8.58%  (p=0.004 n=8+7)
      EncodeComplex128Slice-48    1.14µs ± 2%  0.81µs ± 2%  -28.98%  (p=0.000 n=8+8)
      EncodeFloat64Slice          10.2µs ± 7%  10.1µs ± 6%     ~     (p=0.694 n=7+8)
      EncodeFloat64Slice-6        2.01µs ± 6%  1.80µs ±11%  -10.30%  (p=0.004 n=8+8)
      EncodeFloat64Slice-48        701ns ± 3%   408ns ± 2%  -41.72%  (p=0.000 n=8+8)
      EncodeInt32Slice            11.8µs ± 7%  11.7µs ± 6%     ~     (p=0.463 n=8+7)
      EncodeInt32Slice-6          2.32µs ± 4%  2.06µs ± 5%  -10.89%  (p=0.000 n=8+8)
      EncodeInt32Slice-48          731ns ± 2%   445ns ± 2%  -39.10%  (p=0.000 n=7+8)
      EncodeStringSlice           9.13µs ± 9%  9.18µs ± 8%     ~     (p=0.798 n=8+8)
      EncodeStringSlice-6         1.91µs ± 5%  1.70µs ± 5%  -11.07%  (p=0.000 n=8+8)
      EncodeStringSlice-48         679ns ± 3%   397ns ± 3%  -41.50%  (p=0.000 n=8+8)
      EncodeInterfaceSlice         449µs ±11%   461µs ± 9%     ~     (p=0.328 n=8+8)
      EncodeInterfaceSlice-6       503µs ± 7%    88µs ± 7%  -82.51%  (p=0.000 n=7+8)
      EncodeInterfaceSlice-48      335µs ± 8%    22µs ± 1%  -93.55%  (p=0.000 n=8+7)
      DecodeComplex128Slice       67.2µs ± 4%  67.0µs ± 6%     ~     (p=0.721 n=8+8)
      DecodeComplex128Slice-6     22.0µs ± 8%  18.9µs ± 5%  -14.44%  (p=0.000 n=8+8)
      DecodeComplex128Slice-48    46.8µs ± 3%  34.9µs ± 3%  -25.48%  (p=0.000 n=8+8)
      DecodeFloat64Slice          39.4µs ± 4%  40.3µs ± 3%     ~     (p=0.105 n=8+8)
      DecodeFloat64Slice-6        16.1µs ± 2%  11.2µs ± 7%  -30.64%  (p=0.001 n=6+7)
      DecodeFloat64Slice-48       38.1µs ± 3%  24.0µs ± 7%  -37.10%  (p=0.000 n=8+8)
      DecodeInt32Slice            39.1µs ± 4%  40.1µs ± 5%     ~     (p=0.083 n=8+8)
      DecodeInt32Slice-6          16.3µs ±21%  10.6µs ± 1%  -35.17%  (p=0.000 n=8+7)
      DecodeInt32Slice-48         36.5µs ± 6%  21.9µs ± 9%  -39.89%  (p=0.000 n=8+8)
      DecodeStringSlice           82.9µs ± 6%  85.5µs ± 5%     ~     (p=0.121 n=8+7)
      DecodeStringSlice-6         32.4µs ±11%  26.8µs ±16%  -17.37%  (p=0.000 n=8+8)
      DecodeStringSlice-48        76.0µs ± 2%  57.0µs ± 5%  -25.02%  (p=0.000 n=8+8)
      DecodeInterfaceSlice         718µs ± 4%   752µs ± 5%   +4.83%  (p=0.038 n=8+8)
      DecodeInterfaceSlice-6       500µs ± 6%   165µs ± 7%  -66.95%  (p=0.000 n=7+8)
      DecodeInterfaceSlice-48      470µs ± 5%   120µs ± 6%  -74.55%  (p=0.000 n=8+7)
      DecodeMap                   3.29ms ± 5%  3.34ms ± 5%     ~     (p=0.279 n=8+8)
      DecodeMap-6                 7.73ms ± 8%  7.53ms ±18%     ~     (p=0.779 n=7+8)
      DecodeMap-48                7.46ms ± 6%  7.71ms ± 3%     ~     (p=0.161 n=8+8)
      
      https://perf.golang.org/search?q=upload:20170426.4
      
      Change-Id: I335874028ef8d7c991051004f8caadd16c92d5cc
      Reviewed-on: https://go-review.googlesource.com/41872
      Run-TryBot: Bryan Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      c120e449
    • Bryan C. Mills's avatar
      reflect: use sync.Map instead of RWMutex for type caches · 33b92cd6
      Bryan C. Mills authored
      This provides a significant speedup when using reflection-heavy code
      on many CPU cores, such as when marshaling or unmarshaling protocol
      buffers.
      
      updates #17973
      updates #18177
      
      name                       old time/op    new time/op     delta
      Call                          239ns ±10%      245ns ± 7%       ~     (p=0.562 n=10+9)
      Call-6                        201ns ±38%       48ns ±29%    -76.39%  (p=0.000 n=10+9)
      Call-48                       133ns ± 8%       12ns ± 2%    -90.92%  (p=0.000 n=10+8)
      CallArgCopy/size=128          169ns ±12%      197ns ± 2%    +16.35%  (p=0.000 n=10+7)
      CallArgCopy/size=128-6        142ns ± 9%       34ns ± 7%    -76.10%  (p=0.000 n=10+9)
      CallArgCopy/size=128-48       125ns ± 3%        9ns ± 7%    -93.01%  (p=0.000 n=8+8)
      CallArgCopy/size=256          177ns ± 8%      197ns ± 5%    +11.24%  (p=0.000 n=10+9)
      CallArgCopy/size=256-6        148ns ±11%       35ns ± 6%    -76.23%  (p=0.000 n=10+9)
      CallArgCopy/size=256-48       127ns ± 4%        9ns ± 9%    -92.66%  (p=0.000 n=10+9)
      CallArgCopy/size=1024         196ns ± 6%      228ns ± 7%    +16.09%  (p=0.000 n=10+9)
      CallArgCopy/size=1024-6       143ns ± 6%       42ns ± 5%    -70.39%  (p=0.000 n=8+8)
      CallArgCopy/size=1024-48      130ns ± 7%       10ns ± 1%    -91.99%  (p=0.000 n=10+8)
      CallArgCopy/size=4096         330ns ± 9%      351ns ± 5%     +6.20%  (p=0.004 n=10+9)
      CallArgCopy/size=4096-6       173ns ±14%       62ns ± 6%    -63.83%  (p=0.000 n=10+8)
      CallArgCopy/size=4096-48      141ns ± 6%       15ns ± 6%    -89.59%  (p=0.000 n=10+8)
      CallArgCopy/size=65536       7.71µs ±10%     7.74µs ±10%       ~     (p=0.859 n=10+9)
      CallArgCopy/size=65536-6     1.33µs ± 4%     1.34µs ± 6%       ~     (p=0.720 n=10+9)
      CallArgCopy/size=65536-48     347ns ± 2%      344ns ± 2%       ~     (p=0.202 n=10+9)
      PtrTo                        30.2ns ±10%     41.3ns ±11%    +36.97%  (p=0.000 n=10+9)
      PtrTo-6                       126ns ± 6%        7ns ±10%    -94.47%  (p=0.000 n=9+9)
      PtrTo-48                     86.9ns ± 9%      1.7ns ± 9%    -98.08%  (p=0.000 n=10+9)
      FieldByName1                 86.6ns ± 5%     87.3ns ± 7%       ~     (p=0.737 n=10+9)
      FieldByName1-6               19.8ns ±10%     18.7ns ±10%       ~     (p=0.073 n=9+9)
      FieldByName1-48              7.54ns ± 4%     7.74ns ± 5%     +2.55%  (p=0.023 n=9+9)
      FieldByName2                 1.63µs ± 8%     1.70µs ± 4%     +4.13%  (p=0.020 n=9+9)
      FieldByName2-6                481ns ± 6%      490ns ±10%       ~     (p=0.474 n=9+9)
      FieldByName2-48               723ns ± 3%      736ns ± 2%     +1.76%  (p=0.045 n=8+8)
      FieldByName3                 10.5µs ± 7%     10.8µs ± 7%       ~     (p=0.234 n=8+8)
      FieldByName3-6               2.78µs ± 3%     2.94µs ±10%     +5.87%  (p=0.031 n=9+9)
      FieldByName3-48              3.72µs ± 2%     3.91µs ± 5%     +4.91%  (p=0.003 n=9+9)
      InterfaceBig                 10.8ns ± 5%     10.7ns ± 5%       ~     (p=0.849 n=9+9)
      InterfaceBig-6               9.62ns ±81%     1.79ns ± 4%    -81.38%  (p=0.003 n=9+9)
      InterfaceBig-48              0.48ns ±34%     0.50ns ± 7%       ~     (p=0.071 n=8+9)
      InterfaceSmall               10.7ns ± 5%     10.9ns ± 4%       ~     (p=0.243 n=9+9)
      InterfaceSmall-6             1.85ns ± 5%     1.79ns ± 1%     -2.97%  (p=0.006 n=7+8)
      InterfaceSmall-48            0.49ns ±20%     0.48ns ± 5%       ~     (p=0.740 n=7+9)
      New                          28.2ns ±20%     26.6ns ± 3%       ~     (p=0.617 n=9+9)
      New-6                        4.69ns ± 4%     4.44ns ± 3%     -5.33%  (p=0.001 n=9+9)
      New-48                       1.10ns ± 9%     1.08ns ± 6%       ~     (p=0.285 n=9+8)
      
      name                       old alloc/op   new alloc/op    delta
      Call                          0.00B           0.00B            ~     (all equal)
      Call-6                        0.00B           0.00B            ~     (all equal)
      Call-48                       0.00B           0.00B            ~     (all equal)
      
      name                       old allocs/op  new allocs/op   delta
      Call                           0.00            0.00            ~     (all equal)
      Call-6                         0.00            0.00            ~     (all equal)
      Call-48                        0.00            0.00            ~     (all equal)
      
      name                       old speed      new speed       delta
      CallArgCopy/size=128        757MB/s ±11%    649MB/s ± 1%    -14.33%  (p=0.000 n=10+7)
      CallArgCopy/size=128-6      901MB/s ± 9%   3781MB/s ± 7%   +319.69%  (p=0.000 n=10+9)
      CallArgCopy/size=128-48    1.02GB/s ± 2%  14.63GB/s ± 6%  +1337.98%  (p=0.000 n=8+8)
      CallArgCopy/size=256       1.45GB/s ± 9%   1.30GB/s ± 5%    -10.17%  (p=0.000 n=10+9)
      CallArgCopy/size=256-6     1.73GB/s ±11%   7.28GB/s ± 7%   +320.76%  (p=0.000 n=10+9)
      CallArgCopy/size=256-48    2.00GB/s ± 4%  27.46GB/s ± 9%  +1270.85%  (p=0.000 n=10+9)
      CallArgCopy/size=1024      5.21GB/s ± 6%   4.49GB/s ± 8%    -13.74%  (p=0.000 n=10+9)
      CallArgCopy/size=1024-6    7.18GB/s ± 7%  24.17GB/s ± 5%   +236.64%  (p=0.000 n=9+8)
      CallArgCopy/size=1024-48   7.87GB/s ± 7%  98.43GB/s ± 1%  +1150.99%  (p=0.000 n=10+8)
      CallArgCopy/size=4096      12.3GB/s ± 6%   11.7GB/s ± 5%     -5.00%  (p=0.008 n=9+9)
      CallArgCopy/size=4096-6    23.8GB/s ±16%   65.6GB/s ± 5%   +175.02%  (p=0.000 n=10+8)
      CallArgCopy/size=4096-48   29.0GB/s ± 7%  279.6GB/s ± 6%   +862.87%  (p=0.000 n=10+8)
      CallArgCopy/size=65536     8.52GB/s ±11%   8.49GB/s ± 9%       ~     (p=0.842 n=10+9)
      CallArgCopy/size=65536-6   49.3GB/s ± 4%   49.0GB/s ± 6%       ~     (p=0.720 n=10+9)
      CallArgCopy/size=65536-48   189GB/s ± 2%    190GB/s ± 2%       ~     (p=0.211 n=10+9)
      
      https://perf.golang.org/search?q=upload:20170426.3
      
      Change-Id: Iff68f18ef69defb7f30962e21736ac7685a48a27
      Reviewed-on: https://go-review.googlesource.com/41871
      Run-TryBot: Bryan Mills <bcmills@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      33b92cd6
    • Elias Naur's avatar
      misc/ios: increase iOS test harness timeout · 6e54fe47
      Elias Naur authored
      The "lldb start" phase often times out on the iOS builder. Increase
      the timeout and see if that helps.
      
      Change-Id: I92fd67cbfa90659600e713198d6b2c5c78dde20f
      Reviewed-on: https://go-review.googlesource.com/41863Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Elias Naur <elias.naur@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      6e54fe47
    • Weichao Tang's avatar
      net/http: close resp.Body when error occurred during redirection · e51e0f9c
      Weichao Tang authored
      Fixes #19976
      
      Change-Id: I48486467066784a9dcc24357ec94a1be85265a6f
      Reviewed-on: https://go-review.googlesource.com/40940
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      e51e0f9c
    • Wei Xiao's avatar
      cmd/internal/obj/arm64: fix encoding of condition · 2b6c58f6
      Wei Xiao authored
      The current code treats condition as special register and write
      its raw data directly into instruction.
      
      The fix converts the raw data into correct condition encoding.
      Also fix the operand catogery of FCCMP.
      
      Add tests to cover all cases.
      
      Change-Id: Ib194041bd9017dd0edbc241564fe983082ac616b
      Reviewed-on: https://go-review.googlesource.com/41511
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      2b6c58f6