Summary:
With this patch, llgo uses ssautil.Switches
to reconstitute (and synthesise) switches,
which can then be lowered to lookup tables,
trees, etc.
We currently only handle integer const case
switches. We erase the comparison blocks (other
than the initial block), and generate a switch
instruction at the end of the block starting
the if-else-if chain. ssautil.Switches does
not remove duplicate const cases (e.g. same
operands for "||"), so we do this in llgo for
now.
Test Plan: lit test added
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6831
llvm-svn: 225433
Summary: If a receive case in a select statement is not assigned to a named variable, then we can eliminate the alloca and copy at runtime.
Test Plan: lit test added
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6785
llvm-svn: 225033
The new ABI is simpler for use cases such as dynamically loaded packages.
The calling convention for import functions is similar to what go/ssa would
produce if BareInits were cleared. However, simply clearing this flag causes
two additional issues:
1) We would need to special case the 'init$guard' variable (see
discussion in https://codereview.appspot.com/78780043/).
2) The call to __go_register_gc_roots needs to appear in the right
place, i.e. after the guard check. Making this check appear
in the right place with non-bare inits seems unreliable at best.
So we keep BareInits set and generate the necessary code manually.
It is still possible to get the old ABI by specifying a path to a gccgo
installation.
Differential Revision: http://reviews.llvm.org/D6804
llvm-svn: 225030
Patch by Andrew Wilkins!
canAvoidElementLoad and canAvoidLoad were incorrectly
eliding loads when an index expression is used as an
another array index expression. This led to a panic.
See comments on https://github.com/go-llvm/llgo/issues/175
Test Plan: lit test added
Differential Revision: http://reviews.llvm.org/D6676
llvm-svn: 224420
If we use the receiver's package, we can end up with identical manglings
for different functions. Consider:
package p
type U struct{}
func (U) f()
package q
import "p"
type T struct { p.U }
func (T) f()
The method set of *T has two synthetic methods named (*T).f(); one forwards to
(T).f(), and the other to (U).f(). Previously, we were distinguishing them
by the receiver's package, and in this case because both methods have the
same receiver, they received the same name.
The methods are correctly distinguished by the package owning the identifier
"f", which is available via f.Object().Pkg().
Differential Revision: http://reviews.llvm.org/D6673
llvm-svn: 224357
Peter Collingbourne