Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Based on patch by Rainer Orth.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176938
From-SVN: r271135
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176001
From-SVN: r271019
|
|
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
|
|
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
|
|
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175557
From-SVN: r271014
|
|
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
|
|
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
|
|
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
|
|
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
|
|
The corresponding Go Toolchain patch is CL 164039
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/175079
From-SVN: r270857
|
|
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
|
|
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
|