After spending a truly obnoxious amount of time fighting capnp and
libkj, we made the decision to switch to another RPC system. We're no
longer modeling and serializing message types in Capnp and we don't need
the performance which capnp/libkj RPC promises, so there's really no
need for the additional complexity. A slower system which is thread safe
should work fine.
This commit breaks the build in a pretty horrible way and is not
intended to be merged on its own. It simply breaks up the diff.
This is the first PR in a longer chain that adds basic SV support to
CIRCT.
Add the Slang Verilog frontend as a CIRCT dependency. This will be the
foundation for CIRCT's Verilog parsing, elaboration, type checking, and
lowering to the core dialects. By default, Slang is built as a static
library from scratch, which is then linked into the new `ImportVerilog`
conversion. Alternatively, CIRCT can also be linked against a local
Slang installation provided by the system.
Add the `ImportVerilog` conversion library. This library statically
links in the Slang dependency and wraps it in an exception-safe,
LLVM-style API. Currently this only consists of the `getSlangVersion`
function and the necessary linking flags to get it to link statically
against Slang.
Add the `circt-verilog` tool, which will provide a fully-flegded
interface to the new `ImportVerilog` library. Later on we'll also add an
MLIR translation library for single-file SV import. But in general, SV
builds take a lot of command line options (macros, search paths, etc.)
and multiple input files, which is why we have a dedicated tool. All the
tool does at the moment is print the linked Slang version. More to come.
Note that this intentionally links against **version 3** of Slang. Newer
versions are available -- 4 and 5 as of this commit -- but they rely on
fairly new C++ compiler features that didn't work out of the box in our
CI images. We'll eventually want to upgrade, but for now Slang 3 is
sufficient to get the ball rolling.
See https://github.com/MikePopoloski/slang for details on Slang.
Co-authored-by: ShiZuoye <albertethon@163.com>
Co-authored-by: hunterzju <hunter_ht@zju.edu.cn>
Co-authored-by: 孙海龙 <hailong.sun@terapines.com>
Remove an explicit step in nightly and short integration tests that print
the ccache stats. This is already, conveniently, printing by the action
as part of the "Post ccache" step.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Short integration tests are filling the cache. Hopefully not appending
the timestamp will replace rather than add new ones. Also attempt to
enable sharing cache between nightly and short.
With our custom ccache stuff, cache hits don't update the ccache. This
is problematic since a the ccache might have a high miss rate. Switching
back to the ccache action as I'm assuming it's smarter than that.
Our llvm-lit arguments default to `-sv`, which makes the output succinct
and nice for interactive everyday use. However, in CI, we likely want to
see a more traditional output such that we can easily observe if tests
get stuck.
Add a `LLVM_LIT_ARGS` define to all CI cmake invocations that passes
just `-v` instead of `-sv`, to make lit output one line per tests that
is easily observable in the CI logs.
1. test: tweak test discovery to enable unittests, fix deps var.
Discovery will find the generated lit.site.cfg.py, which
knows how to load the lit.cfg.py.
This could be gated on whether we're building "standalone",
as flang does, but that still doesn't work as we are not part
of the config mapping.
cc #2750.
Also fixup typo in variable name, .._DEPS -> .._DEPENDS.
2. cmake: gtest is available if built with LLVM, set accordingly.
We only include the unittests directory if we think the GTEST bits
are available, which we were not indicating in the non-standalone case.
Fix this, and FWIW this is also done in flang's CMakeLists.txt .
3. [CI] Add check-circt-unit to testing.
GCC debug binaries are just too large and have been causing disk space issues intermittently. Just disable them for now as it is a longer effort to cut down on the amount of stuff we build. Fixes#3328 .
This commit introduces the base classes and utilities to implement
emission patterns and an emission printer which takes the role of a
driver that can be called in a circt-translate pass. Also includes
emission patterns for the builtin module and SCModule operations to
(1) allow to implement some basic unit and integration tests
(2) show the reviewer how emission patterns look like using this
infrastructure.
Different build configurations were previously trampling on the same
cache directory on the build host. The cache directory wasn't
configurable, so just use the cache action directly.
This is mostly mechanical for us. Some notable changes:
* Require a unified build for Python in CMake, docs, and CI
* New CMake defaults for some variables in CMakeLists.txt
* Use the new CMake functions for Python bindings and PyCDE
* Update imports for generated Python and Python extension libraries
* Update PYTHONPATH to reflect the new location under unified builds
* Use the `Python3_EXECUTABLE` found by CMake itself (alongside the libs
and includes) to execute integration tests. This should no longer
require explicitly specifying a python executable in most cases. Where
needed, users can always override `Python3_EXECUTABLE`.
* Add `capnp` requirement on ESI tests. Otherwise the test fails on
systems that build the Python bindings but have no capnp.
* Add some guidance for users that are mainly interested in the Python
bindings of CIRCT. Fixes#1072.
This adds a -shared-libs option to llhd-sim that is analogous to the
same option for mlir-cpu-runner. If specified, those libraries are
passed to the ExecutionEngine to dynamically load and link.
The `ubuntu-latest` tag is starting to point to Ubuntu 20.04, and this seemed to be causing issues related to finding `llvm-lit`. Stick to Ubuntu 18.04 explicitly for now.
This is the first step towards #710. This should be the minimal amount
of boilerplate to set up a Python module such that we can write
`import circt`. Note that this module does not actually bind to or
expose any API at the moment; this is just the boilerplate, and that
will follow.
The setup here is based on both the upstream MLIR Python bindings, as
well as what NPComp does.
This PR expands the nightly builds to run more of our supported build
configurations. This adds (almost) all combinations of the following
variables:
```
CXX = [clang++, g++]
BUILD_SHARED_LIBS = [ON, OFF]
LLVM_ENABLE_ASSERTION = [ON, OFF]
CMAKE_BUILD_TYPE = [Release, Debug]
```
The gcc+sharedlibs combinations have been disabled (see issue #708).
This leads to a total of 12 builds. Every build shares the same cached
version of LLVM and should only take a couple of minutes for each to
complete.
BUILD_SHARED_LIBS builds all libraries as shared libraries.
Historically, this has mostly been used as a developer productivity
flag, as it greatly speeds up linking. The real value in testing with
this flag enabled is that it reveals mistakes in CMake library
dependencies, such as missing dependencies and circular dependencies.
Additionally, there has been recent effort to increase the level of
support for shared libraries to enable MLIR C/Python bindings, and
supporting this flag down the line is probably a must.
John Demme