Stream: t-compiler/wg-mir-opt

Topic: const-prop post insantiation


Giovanni Bajo (Dec 03 2019 at 01:36, on Zulip):

Hi! About the constant propagation: I have a large generic that can benefit from it a lot but post-instantiation. Is this something that the new pass will still improve? Or does it only work pre-instantiation?

Wesley Wiser (Dec 03 2019 at 02:01, on Zulip):

@Giovanni Bajo MIR optimizations are currently just pre-instantiation so it's unlikely to help. If you can provide a sample though, we can test and verify for sure.

Wesley Wiser (Dec 03 2019 at 02:12, on Zulip):

Actually, let me walk some of that back. Even in a generic function, we can sometimes still perform optimizations in a generic context. If you can link to the code, I'd be happy to take a look. That may also give us some ideas for future improvements or other optimizations.

oli (Dec 03 2019 at 07:11, on Zulip):

Also once it gets inlined into a less generic context we can optimize there

Giovanni Bajo (Dec 04 2019 at 23:48, on Zulip):

[]

Giovanni Bajo (Dec 04 2019 at 23:50, on Zulip):

Giovanni Bajo MIR optimizations are currently just pre-instantiation so it's unlikely to help. If you can provide a sample though, we can test and verify for sure.

The code is a MIPS64 interpreter (part of my Nintendo64 emulator). The MIPS architecture consists of several generation where new opcodes were added (and sometimes removed) over the years. The interpreter core is a generic parametrized over a trait which describes the architecture. Since each architecture can basically disable specific opcodes, and (for performance reasons too long to explain) I don't have an enum representing each opcode, I ended up using a function called with literal strings.

Example of opcode:
https://github.com/rasky/r64emu/blob/74c82c6b0e90c2efd7fbe613944f0fd9807ec90b/emu/cpu/mips64/src/cpu.rs#L314

Example of architecture disabling opcodes:
https://github.com/rasky/r64emu/blob/74c82c6b0e90c2efd7fbe613944f0fd9807ec90b/emu/cpu/mips64/src/arch.rs#L55

All the has_op function called are removed by LLVM optimizer, but I'm sure it generates lots of code that is then removed.

Last update: Dec 12 2019 at 01:35UTC