profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mikeurbach/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

mikeurbach/2048 0

A small clone of 1024 (https://play.google.com/store/apps/details?id=com.veewo.a1024)

mikeurbach/charts 0

Curated applications for Kubernetes

mikeurbach/circt 0

Circuit IR Compilers and Tools

mikeurbach/client_ruby 0

Prometheus instrumentation library for Ruby applications

mikeurbach/dalli 0

High performance memcached client for Ruby

mikeurbach/derpcode 0

A tape-based esoteric language based on internet slang.

mikeurbach/firedrake 0

Fast websocket server library.

mikeurbach/javascriptless 0

animations, but with less.js powered css rather than javascript

mikeurbach/kafka 0

Mirror of Apache Kafka

PullRequestReviewEvent

Pull request review commentllvm/circt

[Calyx] Add CalyxToSV scaffolding.

+//===- CalyxToSV.cpp - Translate Calyx into SV ----------------------------===//+//+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.+// See https://llvm.org/LICENSE.txt for license information.+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception++//===----------------------------------------------------------------------===//+//+// This is the main Calyx to SV Conversion Pass Implementation.+//+//===----------------------------------------------------------------------===//++#include "circt/Conversion/CalyxToSV/CalyxToSV.h"+#include "../PassDetail.h"+#include "circt/Dialect/Calyx/CalyxOps.h"+#include "circt/Dialect/SV/SVOps.h"+#include "mlir/Transforms/DialectConversion.h"+#include "mlir/Transforms/Utils.h"++using namespace mlir;+using namespace circt;+using namespace circt::calyx;+using namespace circt::sv;++namespace {+class CalyxToSVPass : public CalyxToSVBase<CalyxToSVPass> {+public:+  void runOnOperation() override;+};+} // end anonymous namespace++void CalyxToSVPass::runOnOperation() {+  // auto op = getOperation();+  ConversionTarget target(getContext());+  target.addIllegalDialect<CalyxDialect>();+  target.addLegalDialect<SVDialect>();

Re-iterating previous comments, I'd expect you'd want the HW and Comb dialects here, if using the dialect conversion framework.

cgyurgyik

comment created time in 3 hours

Pull request review commentllvm/circt

[Calyx] Add CalyxToSV scaffolding.

  include "mlir/Pass/PassBase.td" +//===----------------------------------------------------------------------===//+// CalyxToSV+//===----------------------------------------------------------------------===//++def CalyxToSV : Pass<"lower-calyx-to-sv", "mlir::ModuleOp"> {+  let summary = "Lower Calyx to SV";+  let description = [{+    This pass lowers Calyx to SV.+  }];+  let constructor = "circt::createCalyxToSVPass()";+  let dependentDialects = ["sv::SVDialect"];

Also, will this generate any Comb ops, or have those already been generated by the previous passes?

cgyurgyik

comment created time in 3 hours

Pull request review commentllvm/circt

[Calyx] Add CalyxToSV scaffolding.

  include "mlir/Pass/PassBase.td" +//===----------------------------------------------------------------------===//+// CalyxToSV+//===----------------------------------------------------------------------===//++def CalyxToSV : Pass<"lower-calyx-to-sv", "mlir::ModuleOp"> {+  let summary = "Lower Calyx to SV";+  let description = [{+    This pass lowers Calyx to SV.+  }];+  let constructor = "circt::createCalyxToSVPass()";+  let dependentDialects = ["sv::SVDialect"];

This may be using the SV dialect, but it will probably need the HW dialect, at least for modules.

Depending on exactly how many SV-specific features this uses, I might even name the pass Calyx-to-HW. Unless this is taking advantage of things like interfaces that are SV-only, I would expect this pass to be a "to HW" pass for the most part. For example, that's how FIRRTL names its lowering into the core dialects.

cgyurgyik

comment created time in 3 hours

Pull request review commentllvm/circt

[Calyx] Add CalyxToSV scaffolding.

+//===- CalyxToSV.cpp - Translate Calyx into SV ----------------------------===//+//+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.+// See https://llvm.org/LICENSE.txt for license information.+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception++//===----------------------------------------------------------------------===//+//+// This is the main Calyx to SV Conversion Pass Implementation.+//+//===----------------------------------------------------------------------===//++#include "circt/Conversion/CalyxToSV/CalyxToSV.h"+#include "../PassDetail.h"+#include "circt/Dialect/Calyx/CalyxOps.h"+#include "circt/Dialect/SV/SVOps.h"+#include "mlir/Transforms/DialectConversion.h"

Have you thought about how you'd use the dialect conversion framework here? I'm a fan of this, but it does require a different style of pass compared to how the other Calyx passes work. It may be a good tool for this conversion, so I'm not trying to dissuade you. But you don't have to use it just because you're doing a "conversion". If you already have an algorithm in mind, it is sometimes easier to implement it using the APIs you've already worked with rather than the dialect conversion framework.

cgyurgyik

comment created time in 3 hours

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventllvm/circt

Mike Urbach

commit sha 0756fdf31c687bb3c0786a74c0db96e5f3dffdf3

Trim more unneeded deps while we're at it.

view details

push time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

This doesn't solve the problem in any way... but I just checked and it should work with upstream MLIR right now.

mikeurbach

comment created time in 3 days

push eventllvm/circt

Mike Urbach

commit sha 7fcdecaf70aa4f121be362687269e729dbe4ac3d

Trim unnecessary dependencies from Python bindings.

view details

push time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

Well, I just realized the file we don't actually need the builtin dialect dependency, so we can effectively work around this until we figure out how to include generated files for the upstream dialects. I'm pushing a patch to this branch that does that.

mikeurbach

comment created time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

It's strange, and again only happens with make not ninja. For one, we don't actually care about the file make is complaining about, so I've replaced

MLIRPythonSources

with

MLIRPythonSources.Core
MLIRPythonSources.Dialects.builtin

To try and scope the dependencies to what we actually care about. In this case, depending on the builtin dialect like that still fails to find the _builtin_ops_gen.py file. I am not sure why...

I tried tweaking this upstream to point to ${ARG_ADD_TO_PARENT} instead of ${_dialect_target}, and somehow removing that indirection appeased make and the project built. However, at runtime I realized the generated file hadn't been added to build/tools/circt/python_packages/circt_core/mlir/dialects/. The builtin.py and the _builtin_ops_ext.py files were there, but the generated file didn't appear to have been generated at all.

I'm not sure the tweak I made made any sense, but it seems like something fishy is going on with declare_mlir_dialect_python_bindings that works for the ninja generator but not make. Another possibility is there is some bug specific to the make generator, but I haven't looked into that.

I'm gonna have to step away from this for the evening, but if it's blocking development, I guess I'd recommend using ninja+ccache to try and speed up the rebuilds with ninja while we figure out make.

mikeurbach

comment created time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

FWIW I can reproduce this.. I will try to find a fix.

mikeurbach

comment created time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

gmake[3]: *** No rule to make target 'tools/mlir/python/dialects/_async_dialect_ops_gen.py'

Hmmm, I'm not sure about this. CIRCTMLIRPythonModules depends on MLIRPythonSources, which should include the file gmake is complaining about. I've only tested the Ninja generator, but I can try to reproduce this and fix it.

mikeurbach

comment created time in 3 days

pull request commentllvm/circt

[CMake] Ensure the build directory for generated Python exists.

@teqdruid I think this should fix the issue you were seeing with make based builds.

@stellaraccident for context, we found the build works fine with ninja, but with make this directory doesn't get created automatically, and the mlir-tblgen calls fail. And for various reasons, we want to support make. Is there a better way to solve this? Perhaps the declare_mlir_dialect_python_bindings function could ensure the directory exists? Or maybe there's another way?

mikeurbach

comment created time in 4 days

PR opened llvm/circt

[CMake] Ensure the build directory for generated Python exists.

Ninja is able to generate this, but make does not, and the build fails.

+5 -0

0 comment

1 changed file

pr created time in 4 days

create barnchllvm/circt

branch : cmake-python-dir

created branch time in 4 days

delete branch llvm/circt

delete branch : cmake-visibility

delete time in 4 days

push eventllvm/circt

mikeurbach

commit sha a2ccc01f141f9ddef8bc566e172969f5c3806d9b

[CMake] Only tweak linking settings when doing a unified build. (#1493) When building CIRCT standalone, it isn't safe to assume these configurations can be applied, since the build of LLVM may have used a different configuration. These keeps the same recommended defaults, but only for a unified build via LLVM_EXTERNAL_PROJECTS.

view details

push time in 4 days

PR merged llvm/circt

[CMake] Only tweak linking settings when doing a unified build.

When building CIRCT standalone, it isn't safe to assume these configurations can be applied, since the build of LLVM may have used a different configuration. These keeps the same recommended defaults, but only for a unified build via LLVM_EXTERNAL_PROJECTS.

+16 -16

1 comment

1 changed file

mikeurbach

pr closed time in 4 days

pull request commentllvm/circt

[CMake] Only tweak linking settings when doing a unified build.

Awesome, thanks for verifying the fix!

mikeurbach

comment created time in 4 days

PR opened llvm/circt

Reviewers
[CMake] Only tweak linking settings when doing a unified build.

When building CIRCT standalone, it isn't safe to assume these configurations can be applied, since the build of LLVM may have used a different configuration. These keeps the same recommended defaults, but only for a unified build via LLVM_EXTERNAL_PROJECTS.

+16 -16

0 comment

1 changed file

pr created time in 4 days

create barnchllvm/circt

branch : cmake-visibility

created branch time in 4 days

pull request commentllvm/circt

Add a FIR emitter

@cgyurgyik here's a good example of how you can translate from the MLIR IR for a given dialect back to the format external tools understand. I previously suggested you could do something like this for Calyx if you wanted to kick things back to the existing compiler.

fabianschuiki

comment created time in 4 days

PullRequestReviewEvent

pull request commentllvm/circt

Add a FIR emitter

FYI there was no issue for this, but this feature was previously requested: https://llvm.discourse.group/t/firrtl-dialect-back-to-firrtl/2548/6. I don't know Drew's github handle but I'll tag him.

fabianschuiki

comment created time in 4 days

issue closedllvm/circt

[FIRRTL] LowerTypes pass does unnecessary work for arguments that are unchanged

In the original PR to add this pass, lowered arguments get added to the end of the argument list in order to avoid trampling on existing arguments' attributes. One implication of this is that all original arguments (even if they don't change) must also be copied to the end of the list so they can keep their relative order. There is more discussion on this comment in the original PR: https://github.com/llvm/circt/pull/157#discussion_r524443743.

We can optimize this pass so that it doesn't do this unnecessary copying and rewriting for unchanged arguments. It will require more bookkeeping in order to keep things straight, but it should be possible.

closed time in 4 days

mikeurbach