Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

llvm backend (online) #8

Open
fredrikbk opened this issue Feb 10, 2017 · 4 comments
Open

llvm backend (online) #8

fredrikbk opened this issue Feb 10, 2017 · 4 comments
Assignees
Labels
feature Indicates new feature requests

Comments

@fredrikbk
Copy link
Contributor

We need to develop an llvm backend in the same style as Simit/Halide. This backend should support compiling the taco IR to llvm IR and then have llvm compile the llvm IR to a function pointer.

@fredrikbk fredrikbk added the feature Indicates new feature requests label Feb 10, 2017
@fredrikbk fredrikbk added this to the Beta release milestone Mar 19, 2017
@fredrikbk fredrikbk removed this from the Beta release milestone May 14, 2017
@shoaibkamil shoaibkamil self-assigned this May 15, 2017
@shoaibkamil
Copy link
Contributor

shoaibkamil commented May 15, 2017

I propose we use the ORC JIT mechanism introduced in LLVM 3.7. This (vs. MCJIT from LLVM 2.9+) has some advantages including lazy compilation, a more reasonable and thin API, better memory management, and is more future-proof than MCJIT.

Potential downsides: ORC has not been overly performance optimized, but that is just about compilation time.

@fredrikbk
Copy link
Contributor Author

Sounds reasonable to me. I'm not worried about the optimization; I'm sure that will come. The main selling point for me is the future-proof-ness.

@ElTantawy
Copy link

ElTantawy commented Jul 26, 2017

Hey guys, great work!

I was curious about what prevents taco from being part of Halide. After all, besides sparsity, tensor algebra computations can benefit from tiling, vectorization, parallelization, etc, which are all represented in Halide.

Is the main challenge that Halide is design for linear algebra and not tensor algebra? or it is more of an engineering choice now to avoid disturbing Halide development with major changes? or because they serve two different application domains?

P.S. This question comes from someone whose only experience with either taco or Halide is that he read their papers :).

@fredrikbk
Copy link
Contributor Author

Hi @ElTantawy!

Halide is a grid/stencil language with some reduction support. It should be possible to define dense tensor algebra on top of this. The main conceptual difference I see is the general sparsity that taco supports and the complexity that follows. This results in indirect accesses that may or may not work with Halide's internals. We have certainly borrowed from Halide's internal design, and even use some of their error handling code, but I think integrating the code bases would require a lot of work to generalize both. It's probably a great research project to separately create a general substrate that both could use, but engineering-wise I think it would slow down the development of both.

rohany added a commit that referenced this issue Oct 2, 2021
tests: fix cannonMM implementation to scale k with gx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

4 participants