search

vnmakarov / mir

A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
MIT License
2.24k stars 147 forks source link

Question, immintrin.h support planned? #292

Open tim-janik opened 1 year ago

tim-janik commented 1 year ago

My question is if support for immintrin.h (and atomics) is planned to become part of mir. I was considering it for a JIT-ing audio graphs, but that most often needs intrinsics. And I guess auto-vectorization would be out of the question for MIR anyway...

sletz commented 1 year ago

In its current shape, MIR can already be used for audio DSP will quite good performances, see Faust compiling for MIR.

vnmakarov commented 1 year ago

My question is if support for immintrin.h (and atomics) is planned to become part of mir. I was considering it for a JIT-ing audio graphs, but that most often needs intrinsics. And I guess auto-vectorization would be out of the question for MIR anyway...

Thank you for your interest in the project.

Atomics for me is higher priority than immintrin.h. That is because it is a part of C11 standard. and because CRuby (I am trying to implement JIT for it) uses atomics but not immintrin.h. It is also simpler to implement atomics.

Implementing immintrin.h is a big work. I guess it would be done by other people if MIR and C2MIR support asm insns which is even a bigger project.

So atomics in some form will be probably implemented but I don't think I'll work on immintrin.h. Although if somebody implements it for MIR (in case when asm insn will be implemented) , I'd be glad to consider this work for integration into MIR-project.

Some time ago, somebody proposed to add some vector insns for MIR. That time I said no. But now I am more flexible. I think wasm simplified approach to use vector insns could be more viable alternative for adoption (although MIR targets more architectures than wasm and this might be a problem).

tim-janik commented 1 year ago

Atomics for me is higher priority than immintrin.h. That is because it is a part of C11 standard. and because CRuby (I am trying to implement JIT for it) uses atomics but not immintrin.h. It is also simpler to implement atomics.

Yeah, I've read up about the origins, I read all your blog posts about MIR. Very interesting and inspiring, I'm hoping for even more posts about it ;-)

So atomics in some form will be probably implemented but I don't think I'll work on immintrin.h. Although if somebody implements it for MIR (in case when asm insn will be implemented) , I'd be glad to consider this work for integration into MIR-project.

I can understand that. I'm just wondering, wouldn't it make sense to give priority to adding support for asm instructions? That way you could hope for third party submissions for atomics (and possibly intrinsics). Or would that leave WASM unsolved?

vnmakarov commented 1 year ago

Yeah, I've read up about the origins, I read all your blog posts about MIR. Very interesting and inspiring, I'm hoping for even more posts about it ;-)

The next my blogpost will be probably ready in couple months. I am going to describe dynamically specializing IR for CRuby used by MIR-based JIT I am currently working on. And may be in year I am planning a blog post completely devoted to MIR-based JIT for CRuby.

So atomics in some form will be probably implemented but I don't think I'll work on immintrin.h. Although if somebody implements it for MIR (in case when asm insn will be implemented) , I'd be glad to consider this work for integration into MIR-project.

I can understand that. I'm just wondering, wouldn't it make sense to give priority to adding support for asm instructions? That way you could hope for third party submissions for atomics (and possibly intrinsics). Or would that leave WASM unsolved?

Implementing asm extension requires basically to write assembles for targets supported by MIR (x86_64, arm64, ppc64, s390, riscv). It is a huge project. MIR generates very small set of insns of the targets. For this project I need to generate much more insns. Asm-stmt extension in GCC/LLVM is not trivial too (I know it well as I implemented one new feature for GCC asm about 2 years ago).

So I am thinking about simplified approach: asm (some insn binary sequence which will be placed inside generated code: output vars bound to regs, input vars bound to regs: clobbered regs). The user will be responsible for coding the insn himself. Fixed regs saying the compiler what is used and changed by the asm insn.

So the difference with GCC asm is that the user should do encoding and less flexibility to use different regs. MIR (on branch bbv) already has already asm variables (variables bound to the specific target regs). It could help to implement this approach.