aboutsummaryrefslogtreecommitdiff
path: root/gcc/go
AgeCommit message (Collapse)AuthorFilesLines
2019-06-10compiler: support inlining functions that use index expressionsIan Lance Taylor6-11/+129
Also move the determine_types pass on an inlined function body to one place, rather than doing it ad hoc as needed. This adds 79 new inlinable functions in the standard library, such as bytes.HasPrefix and bytes.LastIndexByte. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181261 From-SVN: r272133
2019-06-10compiler: make heap expression's write barrier conditionalIan Lance Taylor4-21/+53
Heap_expression::do_get_backend emits an unconditional write barrier if the type has pointers and it is not a stack allocation. This CL changes it to use a write barrier for the assignment only when write barriers are enabled. While here, also change it to call gcWriteBarrier instead of typedmemmove for pointer-shaped types. For this to work, Function::build needs to be adjusted so that Heap_expression::do_get_backend is called when there is a parent block. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181540 From-SVN: r272132
2019-06-10compiler: permit inlining functions with labels and goto statementsIan Lance Taylor7-25/+321
This permits inlining functions with for loops and some switches, as they are lowered to if and goto statements before exporting them. This by itself only adds three new inlinable functions in the standard library: sort.Search, context.(*emptyCtx).String, and cmd/go/internal/work.(*Builder).disableBuildID. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181197 From-SVN: r272131
2019-06-10compiler: use gcWriteBarrier for pointer-shaped struct/arrayIan Lance Taylor2-9/+16
If a struct/array is pointer-shaped (i.e. having a single field that is pointer-shaped), we can use gcWriteBarrier instead of typedmemmove for the write barrier. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181539 From-SVN: r272130
2019-06-10compiler: make escape analysis work with imported inlineable functionsIan Lance Taylor3-14/+9
The escape analysis was written before we import inlineable function bodies, and in some places it skipped functions that are not in the local package. Now that there are imported function bodies, make the escape analysis work with them. Note that it is necessary for the escape analysis to run on imported function bodies, even if they are already tagged. The tags only have the information of the parameters (receiver, results), but not the internal nodes, e.g. local variables. We still need to do the analysis to get all the information. (In the future maybe we could export/import escape info for internal nodes also, then we don't need to redo the analysis.) Also add assertions to ensure that if we analyze the same function in multiple places, they'd better agree with each other. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181537 From-SVN: r272124
2019-06-07compiler: improve write barrier generationIan Lance Taylor3-7/+116
For string, slice, interface values, do assignments field by field instead of using typedmemmove. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181297 From-SVN: r272055
2019-06-07compiler: support inlining functions with if statementsIan Lance Taylor4-20/+131
This increases the number of inlinable functions from 455 to 500. An example of a newly inlinable function is strings.Compare. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181137 From-SVN: r272045
2019-06-07compiler: do simple deadcode eliminationIan Lance Taylor7-1/+240
Normally the backend will do deadcode elimination and this is sufficient. However, the escape analysis operates on the AST that may have deadcode, and may cause things to escape that otherwise do not. This CL adds a simple deadcode elimination, run before the escape analysis. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/181080 From-SVN: r272043
2019-06-07go/internal/gccgoimporter: ignore unexported and imported namesIan Lance Taylor1-1/+1
Due to inlining, we can now see unexported functions and variables, and functions and variables imported from different packages. Ignore them rather than reporting them from this package. Handle $hash and $equal functions consistently, so that we discard the inline body if there is one. Ignore names created for result parameters for inlining purposes. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180758 From-SVN: r272023
2019-06-06compiler: permit inlining temporary statements and referencesIan Lance Taylor9-6/+255
This increases the number of inlinable functions from 439 to 455. An example is math/bits.Mul32, which uses temporaries to handle the tuple assignment. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180837 From-SVN: r272022
2019-06-06compiler: make use of specialized fast map routinesIan Lance Taylor7-114/+409
In the runtime there are specialized fast map routines for certain kep types. This CL lets the compiler make use of these functions, instead of always using the generic ones. As we now generate multiple versions of map delete calls, to make things easier we delay the expansion of the built-in delete function to flatten phase. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180858 From-SVN: r271983
2019-06-05compiler: inline call expressions and function referencesIan Lance Taylor7-49/+330
Scan inlinable methods for references to global variables and functions (forgot to do that earlier). Track all packages mentioned by exports (that should have been done earlier too). Record assembler name in export data, so that we can inline calls to non-Go functions. Modify gccgoimporter code to skip assembler name. This increases the number of inlinable functions in the standard library from 215 to 439. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180677 From-SVN: r271976
2019-06-05compiler: statically allocate constant interface dataIan Lance Taylor2-4/+21
When converting a constant to interface, such as interface{}(42) or interface{}("hello"), if the interface escapes, we currently generate a heap allocation to hold the constant value. This CL changes it to generate a static allocation instead, as the gc compiler does. This reduces allocations in such cases. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180277 From-SVN: r271945
2019-06-03compiler, runtime, reflect: generate unique type descriptorsIan Lance Taylor6-2/+219
Currently, the compiler already generates common symbols for type descriptors, so the type descriptors are unique. However, when a type is created through reflection, it is not deduplicated with compiler-generated types. As a consequence, we cannot assume type descriptors are unique, and cannot use pointer equality to compare them. Also, when constructing a reflect.Type, it has to go through a canonicalization map, which introduces overhead to reflect.TypeOf, and lock contentions in concurrent programs. In order for the reflect package to deduplicate types with compiler-created types, we register all the compiler-created type descriptors at startup time. The reflect package, when it needs to create a type, looks up the registry of compiler-created types before creates a new one. There is no lock contention since the registry is read-only after initialization. This lets us get rid of the canonicalization map, and also makes it possible to compare type descriptors with pointer equality. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179598 From-SVN: r271894
2019-06-03libgo: delay applying profile stack-frame skip until fixupIan Lance Taylor1-1/+1
When the runtime collects a stack trace to associate it with some profiling event (mem alloc, mutex, etc) there is a skip count passed to runtime.Callers (or equivalent) to skip some known count of frames in order to get to the "interesting" frame corresponding to the profile event. Now that the profiling mechanism uses lazy fixup (when removing compiler artifacts like thunks, morestack calls etc), we also need to move the frame skipping logic after the fixup, so as to insure that the skip count isn't thrown off by these artifacts. Fixes golang/go#32290. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179740 From-SVN: r271892
2019-06-03compiler: permit inlining references to global variablesIan Lance Taylor9-87/+482
This requires tracking all references to unexported variables, so that we can make them global symbols in the object file, and can export them so that other compilations can see the right definition for their own inline bodies. This introduces a syntax for referencing names defined in other packages: a <pNN> prefix, where NN is the package index. This will need to be added to gccgoimporter, but I didn't do it yet since it isn't yet possible to create an object for which gccgoimporter will see a <pNN> prefix. This increases the number of inlinable functions in the standard library from 181 to 215, adding functions like context.Background. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/177920 From-SVN: r271891
2019-06-03runtime: remove unnecessary functions calling between C and GoIan Lance Taylor1-1/+1
These functions were needed during the transition of the runtime from C to Go, but are no longer necessary. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179879 From-SVN: r271890
2019-06-03runtime: fix assembly syntaxIan Lance Taylor1-1/+1
Some assembler doesn't accept ULL suffix. In fact the suffix is not really necessary. Drop it. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/180217 From-SVN: r271883
2019-05-31runtime: drop unused C type reflection codeIan Lance Taylor1-1/+1
In particular, drop __go_type_descriptors_equal, which is no longer used, and will be made obsolete by CL 179598. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179858 From-SVN: r271823
2019-05-31compiler: optimize append of makeIan Lance Taylor7-84/+251
The gc compiler recognizes append(s, make([]T, n)...), and generates code to directly zero the tail instead of allocating a new slice and copying. This CL lets the Go frontend do basically the same. The difficulty is that at the point we handle append, there may already be temporaries introduced (e.g. in order_evaluations), which makes it hard to find the append-of-make pattern. The compiler could "see through" the value of a temporary, but it is only safe to do if the temporary is not assigned multiple times. For this, we add tracking of assignments and uses for temporaries. This also helps in optimizing non-escape slice make. We already optimize non-escape slice make with constant len/cap to stack allocation. But it failed to handle things like f(make([]T, n)) (where the slice doesn't escape and n is constant), because of the temporary. With tracking of temporary assignments and uses, it can handle this now as well. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179597 From-SVN: r271822
2019-05-31compiler: handle int-to-string conversion with large integer constantIan Lance Taylor2-4/+13
Currently, Type_conversion_expression::do_is_constant thinks the int-to-string conversion is constant if the integer operand is constant, but Type_conversion_expression::do_get_backend actually generates a call to runtime.intstring if the integer does not fit in a "ushort", which makes it not suitable in constant context, such as static initializer. This CL makes it handle all constant integer input as constant, generating constant string. Fixes golang/go#32347. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179777 From-SVN: r271821
2019-05-31runtime: implement cheaper context switch on Linux/AMD64Ian Lance Taylor1-1/+1
Currently, goroutine switches are implemented with libc getcontext/setcontext functions, which saves/restores the machine register states and also the signal context. This does more than what we need, and performs an expensive syscall. This CL implements a simplified version of getcontext/setcontext, in assembly, that only saves/restores the necessary part, i.e. the callee-save registers, and the PC, SP. A simplified version of makecontext, written in C, is also added. Currently this is only implemented on Linux/AMD64. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178298 From-SVN: r271818
2019-05-30Fix RISC-V build failure for go language.Jim Wilson2-0/+9
gcc/go/ * go-gcc.cc (Gcc_backend::Gcc_backend): Add BUILT_IN_ATOMIC_FETCH_AND_1 and BUILT_IN_ATOMIC_FETCH_OR_1. From-SVN: r271790
2019-05-30compiler: intrinsify sync/atomic functionsIan Lance Taylor3-12/+112
Let the Go frontend recognize sync/atomic functions and turn them into intrinsics. Also make sure not to intrinsify calls in go or defer statements. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178937 From-SVN: r271784
2019-05-30re PR go/90669 (go/gofrontend/types.cc:2805 contains range-based ‘for’ ↵Ian Lance Taylor2-3/+8
loops which are not C++98) PR go/90669 compiler: remove range-based 'for' loop Fix for GCC PR/90669: remove range-based 'for' loop to preserve buildability with g++ version 4.X. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179397 From-SVN: r271761
2019-05-27re PR go/90635 (typo in libgo/configure.ac)Ian Lance Taylor1-1/+1
PR go/90635 libgo: correct typo in USE_LIBFFI AM_CONDITIONAL Only affects the case of passing --without-libffi to configure. Fixes https://gcc.gnu.org/PR90635 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178998 From-SVN: r271640
2019-05-27re PR go/90614 (gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused ↵Ian Lance Taylor1-1/+1
parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)) PR go/90614 syscall: avoid unused parameter error if WIFCONTINUED not defined Fixes https://gcc.gnu.org/PR90614 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178997 From-SVN: r271638
2019-05-17compiler: use SHA1-hash for symname for long gcbits symbolsIan Lance Taylor2-10/+32
The current scheme used by the compiler for "gcbits" symbols involves generating a symbol name based on a 32-char encoding of the bits data. This scheme works well in most cases but can generate very long symbol names in rare cases. To help avoid such long symbol names, switch to a different encoding scheme based on the SHA1 digest of the payload if the symbol size would be too large. Fixes golang/go#32083. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/177598 From-SVN: r271322
2019-05-17re PR go/90482 (Many 32-bit Solaris/SPARC tests FAIL with SIGBUS)Ian Lance Taylor5-19/+42
PR go/90482 compiler: make value method of direct interface type takes pointer Currently, a value method of a direct interface type takes the value of the receiver, which is pointer shaped, as the first parameter. When this method is called through interface, we actually pass the interface data as a pointer. On most platforms this is ok, as the underlying calling convention is the same, except that on SPARC32, the calling convention is actually different. This CL changes the method function actually takes a pointer. The function will convert the pointer to the pointer-shaped receiver type (a no-op conversion from machine code's aspect). For a direct call, in the caller we convert the receiver to a pointer (also no-op conversion) before invoking the method. For an interface call, we pass the pointer as before. This way, it is consistent that we always pass a pointer. Hopefully this fixes SPARC32 build and https://gcc.gnu.org/PR90482. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/177758 From-SVN: r271310
2019-05-17compiler: intrinsify runtime/internal/atomic functionsCherry Zhang6-1/+390
Currently runtime/internal/atomic functions are implemented in C using C compiler intrinsics. This CL lets the Go frontend recognize these functions and turn them into intrinsics directly. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176918 * go-gcc.cc (Gcc_backend::Gcc_backend): Define atomic builtins. From-SVN: r271308
2019-05-16compiler: add intrinsics for runtime/internal/sys functionsIan Lance Taylor7-109/+149
runtime/internal/sys.Ctz32/64 and Bswap32/64 are currently implemented with compiler builtin functions. But if they are called from another package, the compiler does not know and therefore cannot turn them into compiler intrinsics. This CL makes the compiler recognize these functions and turn them into intrinsics directly, as the gc compiler does. This CL sets up a way for adding intrinsics in the compiler. More intrinsics will be added in later CLs. Also move the handling of runtime.getcallerpc/sp to the new way of generating intrinsics. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176917 From-SVN: r271303
2019-05-16compiler: improve escape analysis on interface conversionsCherry Zhang9-22/+360
If an interface does not escape, it doesn't need a heap allocation to hold the data (for non-direct interface type). This CL improves the escape analysis to track interface conversions, and reduces these allocations. Implicit interface conversions were mostly added late in the compilation pipeline, after the escape analysis. For the escape analysis to see them, we move the introduction of these conversions earlier, right before the escape analysis. Now that the compiler can generate interface conversions inlined, gcc/testsuite/go.test/test/nilptr2.go needs to be adjusted as in golang.org/cl/176579, so the use function does an actual use. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176459 * go.test/test/nilptr2.go: Change use function to actually do something. From-SVN: r271276
2019-05-14libgo: reduce overhead for memory/block/mutex profilingIan Lance Taylor1-1/+1
Revise the gccgo version of memory/block/mutex profiling to reduce runtime overhead. The main change is to collect raw stack traces while the profile is on line, then post-process the stacks just prior to the point where we are ready to use the final product. Memory profiling (at a very low sampling rate) is enabled by default, and the overhead of the symbolization / DWARF-reading from backtrace_full was slowing things down relative to the main Go runtime. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/171497 From-SVN: r271172
2019-05-13libgo: drop Solaris 10 supportIan Lance Taylor1-1/+1
Based on patch by Rainer Orth. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176938 From-SVN: r271135
2019-05-11runtime: set up g earlyIan Lance Taylor1-1/+1
runtime.throw needs a g to work properly. Set up g early, to ensure that if something goes wrong in the runtime startup (e.g. runtime.check fails), the program terminates in a reasonable way. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176657 From-SVN: r271088
2019-05-10compiler: permit inlining receive expressionsIan Lance Taylor3-1/+32
This does not permit any new inlinable functions in the standard library. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176637 From-SVN: r271074
2019-05-10compiler: permit inlining variable declaration statementsIan Lance Taylor4-9/+71
This adds all of two inlinable functions to the standard library: crypto/subtle.ConstantTimeLessOrEq, regexp.(*Regexp).Copy. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176378 From-SVN: r271063
2019-05-09compiler: avoid copy for string([]byte) conversion used in map keysCherry Zhang3-1/+15
If a string([]byte) conversion is used immediately as a key for a map read, we don't need to copy the backing store of the byte slice, as mapaccess does not keep a reference to it. The gc compiler does more than this: it also avoids the copy if the map key is a composite literal that contains the conversion as a field, like, T{ ... { ..., string(b), ... }, ... }. For now, we just optimize the simple case, which is probably most common. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176197 * go.dg/mapstring.go: New test. From-SVN: r271044
2019-05-08compiler: avoid copy for string([]byte) conversion used in string comparisonCherry Zhang3-6/+131
If a string([]byte) conversion is used immediately in a string comparison, we don't need to copy the backing store of the byte slice, as the string comparison doesn't hold any reference to it. Instead, just create a string header from the byte slice and pass it for comparison. A new type of expression, String_value_expression, is introduced, for constructing string headers. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/170894 * go.dg/cmpstring.go: New test. From-SVN: r271021
2019-05-08libgo: add Debugging section to READMEIan Lance Taylor1-1/+1
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176001 From-SVN: r271019
2019-05-08compiler: generate memmove for non-pointer slice copyIan Lance Taylor3-56/+134
The builtin copy function is lowered to runtime functions slicecopy, stringslicecopy, or typedslicecopy. The first two are basically thin wrappers of memmove. Instead of making a runtime call, we can just use __builtin_memmove. This gives the compiler backend opportunities for further optimizations. Move the lowering of builtin copy function to flatten phase for the ease of rewriting. Also do this optimization for the copy part of append(s1, s2...). Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/170005 From-SVN: r271017
2019-05-08runtime: use builtin memmove directlyCherry Zhang3-1/+14
We can use the intrinsic memmove directly, without going through C. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/170004 * go-gcc.cc (Gcc_backend::Gcc_backend): Define memmove builtin. From-SVN: r271016
2019-05-08compiler: remove trailing spacesIan Lance Taylor6-15/+15
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175557 From-SVN: r271014
2019-05-08reflect: correctly handle direct interface typed receiver in Value.callIan Lance Taylor1-1/+1
A direct interface type's value method takes value receiver now. Don't pass pointer to the method function. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175798 From-SVN: r271000
2019-05-08compiler: don't add pointer twice to value method of direct interface typeIan Lance Taylor2-10/+12
For a direct interface type T with a value method M, its pointer type (*T)'s method table includes a stub method of M which takes a (*T) as the receiver instead of a T. However, for the "typ" field of the method table entry, we added another layer of indirection, which makes it appear to take a **T, which is wrong. This causes problems when using reflect.Type.Method to get the method. This CL fixes the second, incorrect, indirection. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175837 From-SVN: r270999
2019-05-08compiler: add an option to emit optimization diagnosticsCherry Zhang10-1/+40
Add a -fgo-debug-optimization option to emit optimization diagnostics. This can be used for testing optimizations. Apply this to the range clear optimizations of maps and arrays. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/170002 gcc/go: * lang.opt (-fgo-debug-optimization): New option. * go-c.h (struct go_create_gogo_args): Add debug_optimization field. * go-lang.c (go_langhook_init): Set debug_optimization field. * gccgo.texi (Invoking gccgo): Document -fgo-debug-optimization. gcc/testsuite: * go.dg/arrayclear.go: New test. * go.dg/mapclear.go: New test. From-SVN: r270993
2019-05-03compiler: recognize and optimize array range clearIan Lance Taylor6-2/+279
Recognize for i := range a { a[i] = zero } for array or slice a, and rewrite it to call memclr, as the gc compiler does. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/169398 From-SVN: r270862
2019-05-03os/user: disable TestGroupIds for AIXIan Lance Taylor1-1/+1
The corresponding Go Toolchain patch is CL 164039 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175079 From-SVN: r270857
2019-05-01compiler: recognize and optimize map range clearIan Lance Taylor4-1/+104
Recognize for k := range m { delete(m, k) } for map m, and rewrite it to runtime.mapclear, as the gc compiler does. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/169397 From-SVN: r270780
2019-05-01compiler,runtime: do more direct interfacesIan Lance Taylor6-26/+357
A direct interface is an interface whose data word contains the actual data value, instead of a pointer to it. The gc toolchain creates a direct interface if the value is pointer shaped, that includes pointers (including unsafe.Pointer), functions, channels, maps, and structs and arrays containing a single pointer-shaped field. In gccgo, we only do this for pointers. This CL unifies direct interface types with gc. This reduces allocations when converting such types to interfaces. Our method functions used to always take pointer receivers, to make interface calls easy. Now for direct interface types, their value methods will take value receivers. For a pointer to those types, when converted to interface, the interface data contains the pointer. For that interface to call a value method, it will need a wrapper method that dereference the pointer and invokes the value method. The wrapper method, instead of the actual one, is put into the itable of the pointer type. In the runtime, adjust funcPC for the new layout of interfaces of functions. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/168409 From-SVN: r270779