Summary:
As llgoi is installed, it must be built or the install
target will fail; there is no implicit dependency.
Adding llgoi to "ALL" makes building llgo as part of an
entire LLVM distribution a bit friendlier: you can then
just do the typical "make && make install".
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11291
llvm-svn: 242750
Summary:
This diff is to support Debian packaging,
which sets various hardening-rleated flags
in CFLAGS. They don't make sense for Go,
so we just ignore them.
Reviewers: pcc
Subscribers: llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D11288
llvm-svn: 242513
Summary:
libtool_VERSION was changed in gofrontend a while ago,
but CMakeLists.txt in llgo wasn't updated, and so the
install target fails. Not sure how this went unnoticed
for so long.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11118
llvm-svn: 242291
Summary:
If a function requires a landing pad, set the personality function.
Requires D11116.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11117
llvm-svn: 242290
Summary:
This diff adds line-editing to llgoi, by
vendoring and using github.com/peterh/liner.
I have only implemented the basics here;
follow-ups will come later to add persisted
history, and completion,
Reviewers: pcc
Reviewed By: pcc
Subscribers: axw, llvm-commits
Differential Revision: http://reviews.llvm.org/D9811
llvm-svn: 238100
Summary:
This patch adds the configuration used to deploy
the llgo-builder buildbot slave. The builder is
deployed to Google Compute Engine using Juju.
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8854
llvm-svn: 234383
This takes us to Go 1.4. Also includes a couple of changes to the test
suite, both in the runtime package:
- Disable TestSetPanicOnFault. We cannot support this scenario at all,
due to LLVM's lack of non-call exceptions.
- Tweak TestFinalizerType. This test only passes with two GC runs.
Differential Revision: http://reviews.llvm.org/D8828
llvm-svn: 234134
Most importantly, this gives us https://go-review.googlesource.com/7533 which
fixes a bug in go/ssa that caused test failures in the Go 1.4 standard library.
Also remove the go1.4 tag workaround. We no longer need it now that we
ship llgo-go.
Differential Revision: http://reviews.llvm.org/D8827
llvm-svn: 234133
go/loader creates a fresh package map for each source package it imports. In
llgoi this caused binary imported packages to be imported anew for every input
line, resulting in spurious type errors and panics in go/ssa when encountering
previously imported types. Fix this by setting types.Config.Packages to our
internal package map.
Differential Revision: http://reviews.llvm.org/D8409
llvm-svn: 232617
Note that this means that llgoi does not support the case
where a package's pkgpath is different from its import path,
but I don't think this should actually happen with llgoi.
Differential Revision: http://reviews.llvm.org/D8403
llvm-svn: 232612
Summary:
There are two packages in libgo which have
known failures when running the "make check" rule.
This change disables those packages in the tests so
that we can run libgo tests without them until the
root causes are identified and resolved.
Test Plan: ran check-libgo rule
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8003
llvm-svn: 231448
Summary:
llgo was asserting in DebugInfo, which was interpreting
the temporary MDNodes we were creating as DIScopes instead
of DITypes (in DIScope::getRef).
This proposal changes llgo to use DIBuilder's
createReplaceableCompositeType method to create a DIType
that can be RAUW'd.
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7852
llvm-svn: 230953
Summary:
The debug metadata we generate is wrong, and is
now causing build failures. This revision disables
the only llvm.dbg.declare calls we make.
(There is also a drive-by fix to CMakeLists.txt,
adding in a missing .go dependency.)
Fixes http://llvm.org/bugs/show_bug.cgi?id=22330
Reviewers: pcc
Reviewed By: pcc
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D7222
llvm-svn: 227403
llgoi is a Go REPL based on llgo irgen and the LLVM JIT. It supports
expressions, statements, most declarations and imports, including binary
imports from the standard library and source imports from $GOPATH.
Differential Revision: http://reviews.llvm.org/D6957
llvm-svn: 226097
At the same time, perform a number of simplifications:
- Rename go.tools directory to gotools.
- Import only the go directory; all required Go analysis code and
its dependencies have now been moved to this directory.
llvm-svn: 225825
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
This is useful for clients that need to use llgo's mangling of the package
path to look up a specific function within a given package.
Differential Revision: http://reviews.llvm.org/D6801
llvm-svn: 225027
This change allows clients to generate IR using "files" received from locations
other than the file system. The regular file parser is moved to a new library,
"driver", which is intended to eventually contain much of the logic from
the existing driver.
Differential Revision: http://reviews.llvm.org/D6794
llvm-svn: 225026
multilib build and installs.
Summary:
This requires introducing a generated header to encapsulate the
LLVM_LIBDIR_SUFFIX value from the build system and push it into the go
code. From there, I've adjusted the gllgo code to systematically use
this rather than a raw "lib". This requires some awkwardness as one of
the flags *must* be "lib"-relative for compatibility with how gccgo
works. For that flag, we use ".." to back up a directory and then go
into the proper lib directory.
Differential Revision: http://reviews.llvm.org/D6795
llvm-svn: 224964
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
Tanya Lattner