@@ -226,31 +226,57 @@ <h3 id="vet">Vet</h3>
226
226
227
227
< h2 id ="runtime "> Runtime</ h2 >
228
228
229
- < p > <!-- CL 304470 -->
230
- TODO: < a href ="https://golang.org/cl/304470 "> https://golang.org/cl/304470</ a > : cmd/compile, runtime: add metadata for argument printing in traceback
231
- </ p >
232
-
233
229
< p >
234
230
TODO: complete the Runtime section
235
231
</ p >
236
232
237
233
< h2 id ="compiler "> Compiler</ h2 >
238
234
239
- < p > <!-- CL 283112, golang.org/issue/28727 -->
235
+ < p > <!-- golang.org/issue/40724 -->
236
+ Go 1.17 implements a new way of passing function arguments and results using
237
+ registers instead of the stack. This work is enabled for Linux, MacOS, and
238
+ Windows on the 64-bit x86 architecture (the < code > linux/amd64</ code > ,
239
+ < code > darwin/amd64</ code > , < code > windows/amd64</ code > ports). For a
240
+ representative set of Go packages and programs, benchmarking has shown
241
+ performance improvements of about 5%, and a typical reduction in binary size
242
+ of about 2%.
243
+ </ p >
240
244
245
+ < p >
246
+ This change does not affect the functionality of any safe Go code. It can affect
247
+ code outside the < a href ="/doc/go1compat "> compatibility guidelines</ a > with
248
+ minimal impact. To maintain compatibility with existing assembly functions,
249
+ adapter functions converting between the new register-based calling convention
250
+ and the previous stack-based calling convention (also known as ABI wrappers)
251
+ are sometimes used. This is mostly invisible to users, except for assembly
252
+ functions that have their addresses taken in Go. Using < code > reflect.ValueOf(fn).Pointer()</ code >
253
+ (or similar approaches such as via < code > unsafe.Pointer</ code > ) to get the address
254
+ of an assembly function will now return the address of the ABI wrapper. This is
255
+ mostly harmless, except for special-purpose assembly code (such as accessing
256
+ thread-local storage or requiring a special stack alignment). Assembly functions
257
+ called indirectly from Go via < code > func</ code > values will now be made through
258
+ ABI wrappers, which may cause a very small performance overhead. Also, calling
259
+ Go functions from assembly may now go through ABI wrappers, with a very small
260
+ performance overhead.
261
+ </ p >
262
+
263
+ < p > <!-- CL 304470 -->
264
+ The format of stack traces from the runtime (printed when an uncaught panic
265
+ occurs, or when < code > runtime.Stack</ code > is called) is improved. Previously,
266
+ the function arguments were printed as hexadecimal words based on the memory
267
+ layout. Now each argument in the source code is printed separately, separated
268
+ by commas. Aggregate-typed (struct, array, string, slice, interface, and complex)
269
+ arguments are delimited by curly braces. A caveat is that the value of an
270
+ argument that only lives in a register and is not stored to memory may be
271
+ inaccurate. Results (which were usually inaccurate) are no longer printed.
272
+ </ p >
273
+
274
+ < p > <!-- CL 283112, golang.org/issue/28727 -->
241
275
Functions containing closures can now be inlined. One effect of this change is
242
276
that a function with a closure may actually produce a distinct closure function
243
277
for each place that the function is inlined. Hence, this change could reveal
244
278
bugs where Go functions are compared (incorrectly) by pointer value. Go
245
279
functions are by definition not comparable.
246
-
247
- TODO: complete the Compiler section, or delete if not needed
248
- </ p >
249
-
250
- < h2 id ="linker "> Linker</ h2 >
251
-
252
- < p >
253
- TODO: complete the Linker section, or delete if not needed
254
280
</ p >
255
281
256
282
< h2 id ="library "> Core library</ h2 >
0 commit comments