@@ -401,30 +401,37 @@ <h2 id="compiler">Compiler</h2>
401
401
402
402
< p > <!-- golang.org/issue/40724 -->
403
403
Go 1.17 implements a new way of passing function arguments and results using
404
- registers instead of the stack. This work is enabled for Linux, macOS, and
405
- Windows on the 64-bit x86 architecture (the < code > linux/amd64</ code > ,
406
- < code > darwin/amd64</ code > , < code > windows/amd64</ code > ports). For a
407
- representative set of Go packages and programs, benchmarking has shown
408
- performance improvements of about 5%, and a typical reduction in binary size
409
- of about 2%.
404
+ registers instead of the stack.
405
+ Benchmarks for a representative set of Go packages and programs show
406
+ performance improvements of about 5%, and a typical reduction in
407
+ binary size of about 2%.
408
+ This is currently enabled for Linux, macOS, and Windows on the
409
+ 64-bit x86 architecture (the < code > linux/amd64</ code > ,
410
+ < code > darwin/amd64</ code > , and < code > windows/amd64</ code > ports).
410
411
</ p >
411
412
412
413
< p >
413
- This change does not affect the functionality of any safe Go code. It can affect
414
- code outside the < a href ="/doc/go1compat "> compatibility guidelines</ a > with
415
- minimal impact. To maintain compatibility with existing assembly functions,
416
- adapter functions converting between the new register-based calling convention
417
- and the previous stack-based calling convention (also known as ABI wrappers)
418
- are sometimes used. This is mostly invisible to users, except for assembly
419
- functions that have their addresses taken in Go. Using < code > reflect.ValueOf(fn).Pointer()</ code >
420
- (or similar approaches such as via < code > unsafe.Pointer</ code > ) to get the address
421
- of an assembly function will now return the address of the ABI wrapper. This is
422
- mostly harmless, except for special-purpose assembly code (such as accessing
423
- thread-local storage or requiring a special stack alignment). Assembly functions
424
- called indirectly from Go via < code > func</ code > values will now be made through
425
- ABI wrappers, which may cause a very small performance overhead. Also, calling
426
- Go functions from assembly may now go through ABI wrappers, with a very small
427
- performance overhead.
414
+ This change does not affect the functionality of any safe Go code
415
+ and is designed to have no impact on most assembly code.
416
+ It may affect code that violates
417
+ the < a href ="/pkg/unsafe#Pointer "> < code > unsafe.Pointer</ code > </ a >
418
+ rules when accessing function arguments, or that depends on
419
+ undocumented behavior involving comparing function code pointers.
420
+ To maintain compatibility with existing assembly functions, the
421
+ compiler generates adapter functions that convert between the new
422
+ register-based calling convention and the previous stack-based
423
+ calling convention.
424
+ These adapters are typically invisible to users, except that taking
425
+ the address of a Go function in assembly code or taking the address
426
+ of an assembly function in Go code
427
+ using < code > reflect.ValueOf(fn).Pointer()</ code >
428
+ or < code > unsafe.Pointer</ code > will now return the address of the
429
+ adapter.
430
+ Code that depends on the value of these code pointers may no longer
431
+ behave as expected.
432
+ Adapters also may cause a very small performance overhead in two
433
+ cases: calling an assembly function indirectly from Go via
434
+ a < code > func</ code > value, and calling Go functions from assembly.
428
435
</ p >
429
436
430
437
< p > <!-- CL 304470 -->
@@ -440,11 +447,14 @@ <h2 id="compiler">Compiler</h2>
440
447
</ p >
441
448
442
449
< p > <!-- CL 283112, golang.org/issue/28727 -->
443
- Functions containing closures can now be inlined. One effect of this change is
444
- that a function with a closure may actually produce a distinct closure function
445
- for each place that the function is inlined. Hence, this change could reveal
446
- bugs where Go functions are compared (incorrectly) by pointer value. Go
447
- functions are by definition not comparable.
450
+ Functions containing closures can now be inlined.
451
+ One effect of this change is that a function with a closure may
452
+ produce a distinct closure code pointer for each place that the
453
+ function is inlined.
454
+ Go function values are not directly comparable, but this change
455
+ could reveal bugs in code that uses < code > reflect</ code >
456
+ or < code > unsafe.Pointer</ code > to bypass this language restriction
457
+ and compare functions by code pointer.
448
458
</ p >
449
459
450
460
< h2 id ="library "> Core library</ h2 >
0 commit comments