Граф коммитов

17 коммитов

Автор SHA1 Сообщение Дата
Jaden Weiss
abca3132a9 fix bugs found by LLVM assertions 2019-09-16 18:31:33 +02:00
Ayke van Laethem
10ed3decb0 compiler: rename getZeroValue to llvm.ConstNull
It does the same thing but should be more complete, and it probably is
faster as well (just one CGo call instead of several).
2019-09-15 19:09:10 +02:00
Ayke van Laethem
385d1d0a5d
compiler,runtime: implement a portable conservative GC 2019-07-01 16:30:33 +02:00
Ayke van Laethem
6b5b4a681d compiler: refactor named types to create them lazily
This commit refactors named types to be created lazily. Instead of
defining all types in advance, do it only when necessary.
2019-06-08 22:17:09 +02:00
Ayke van Laethem
9a3d0683b3 compiler: mark all GEPs as inbounds
In Go, it is not possible to construct pointers that are out of bounds
(and not null), so let LLVM know about this fact.

This leads to a significant code size reduction, around 3% in many
cases.
2019-04-26 09:17:52 +02:00
Ayke van Laethem
d155e31b64 all: improve compiler error handling
Most of these errors are actually "todo" or "unimplemented" errors, so
the return type is known. This means that compilation can proceed (with
errors) even though the output will be incorrect. This is useful because
this way, all errors in a compilation unit can be shown together to the
user.
2019-04-26 08:52:10 +02:00
Ayke van Laethem
45cacda7b3 compiler: refactor parseExpr
This commit adds getValue which gets a const, global, or result of a
local SSA expression and replaces (almost) all uses of parseExpr with
getValue. The only remaining use is in parseInstr, which makes sure an
instruction is only evaluated once.
2019-04-26 08:52:10 +02:00
Ayke van Laethem
c25fe609a9 compiler: do not return an error from getLLVMType
This commit replaces "unknown type" errors in getLLVMType with panics.

The main reason this is done is that it simplifies the code *a lot*.
Many `if err != nil` lines were there just because of type information.
Additionally, simply panicking is probably a better approach as the only
way this error can be produced is either with big new language features
or a serious compiler bug. Panicking is probably a better way to handle
this error anyway.
2019-04-26 08:52:10 +02:00
Ayke van Laethem
6d23809218 compiler: simplify code around getZeroValue
The LLVM library we use does not (yet) provide a llvm.Zero (like it
provides a llvm.Undef) so we have implemented our own. However, in
theory it might return an error in some cases.

No real-world errors have been seen in a while and errors would likely
indicate a serious compiler bug anyway (not an external error), so make
it panic instead of returning an error.
2019-04-26 08:52:10 +02:00
Ayke van Laethem
914d383a96
all: update import paths to github.com/tinygo-org/tinygo 2019-01-31 17:43:19 +01:00
Ayke van Laethem
1db9a162da
all: go fmt
The import path changes changed the order of imports, but no `go fmt`
was run before the commit. Oops...
2019-01-31 16:22:05 +01:00
Ayke van Laethem
9092dbcc53
all: rename go-llvm to new import path
the new import path is:

    tinygo.org/x/go-llvm
2019-01-27 19:26:16 +01:00
Ayke van Laethem
602c264749
all: rewrite goroutine lowering
Before this commit, goroutine support was spread through the compiler.
This commit changes this support, so that the compiler itself only
generates simple intrinsics and leaves the real support to a compiler
pass that runs as one of the TinyGo-specific optimization passes.

The biggest change, that was done together with the rewrite, was support
for goroutines in WebAssembly for JavaScript. The challenge in
JavaScript is that in general no blocking operations are allowed, which
means that programs that call time.Sleep() but do not start goroutines
also have to be scheduled by the scheduler.
2019-01-21 22:09:33 +01:00
Ayke van Laethem
564b1b3312
compiler: always use fat function pointers with context
This reduces complexity in the compiler without affecting binary sizes
too much.

Cortex-M0:   no changes
Linux x64:   no changes
WebAssembly: some testcases (calls, coroutines, map) are slightly bigger
2018-12-09 18:47:39 +01:00
Ayke van Laethem
3fec22e819
compiler: avoid function pointers in defer calls
Implement defer in a different way, which results in smaller binaries.
The binary produced from testdata/calls.go (the only test case with
defer) is reduced a bit in size, but the savings in bytes greatly vary
by architecture:

Cortex-M0:    -96 .text / flash
WebAssembly: -215 entire file
Linux x64:    -32 .text

Deferred functions in TinyGo were implemented by creating a linked list
of struct objects that contain a function pointer to a thunk, a pointer
to the next object, and a list of parameters. When it was time to run
deferred functions, a helper runtime function called each function
pointer (the thunk) with the struct pointer as a parameter. This thunk
would then in turn extract the saved function parameter from the struct
and call the real function.

What this commit changes, is that the loop to call deferred functions is
moved into the end of the function (practically inlining it) and
replacing the thunks with direct calls inside this loop. This makes it
much easier for LLVM to perform all kinds of optimizations like inlining
and dead argument elimination.
2018-12-09 16:44:37 +01:00
Ayke van Laethem
23b283366d
compiler: add header comment to defer.go 2018-12-01 22:43:01 +01:00
Ayke van Laethem
69fbfbddbb
compiler: move defer code out of compiler.go
This puts all defer-related code into a single file, making it easier to
understand it.
2018-12-01 19:23:56 +01:00