Plans for Maglev code generator

[Iurii Zamiatin]

Hi,

We want to clarify something w.r.t future plans for the Maglev code generator.

Maglev right now is a very "coarse-grained" compiler - most bytecode operations are lowered to a single Maglev node selected based on feedback (design doc for Maglev also refers to these as macro-ops). This is contrast with TF (and TS) that is way more "fine-grained" - a single node can be lowered to a CFG fragment with many low-level machine operations.

Would it be fair to assume that Maglev will stay "coarse-grained" for the foreseeable future? If that is the case, should we assume that the best way to port machine rewriter's optimizations/instruction selection patterns from TF to Maglev is to add these optimizations to GenerateCode methods?

Finally, what will Maglev pipeline ultimately look like? Is the design document for Maglev up to date with respect to future plans? Will there be any infrastructure for folding nodes outside of the graph builder?

Thanks,
Iurii

[Leszek Swirski]

Hi Iurii,

Without making any strict promises, we expect the coarseness of the maglev compiler to stay roughly at the level it is, with instruction-level optimisations being implemented in GenerateCode methods or Maglev/MacroAssembler helper methods.

We're also not anticipating any large changes to the pipeline from the design doc, which hasn't been updated but is still roughly accurate. The guiding principle of maglev is to have only a single IR (i.e. minimise reductions from high-level IR node to low-level IR node, preferring direct lowering to the latter node) and minimal passes. That said, we do have a second pass for trying to eliminate conversions around phis, and we _may_ want to look into non-greedy inlining at some point, which would require lowering calls into an inlined graph and propagating inlined information through the remaining graph (likely folding away constants, known branches, known checks, etc.).

Does this answer your questions? Happy to expand on these.

Leszek

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/86ab2a6b-c211-4435-b015-6b44bece452cn%40googlegroups.com.

[Iurii Zamiatin]

Hi Leszek,

Yes, that clears it up, thanks. We have three follow up questions.

1) Are there any plans to add additional testing infrastructure for Maglev? Given that codegen for some nodes is quite complicated, it could be beneficial to test code for some of the nodes in isolation.
2) With respect to folding, are there any plans to replace nodes with more specialized counterparts (e.g. how this comment suggests)?
3) If we can significantly improve performance by moving one of the GenerateCode methods out of the "maglev-ir.cc" file into an architecture-specific folder, what is the best way to incorporate these changes?

Iurii

[Leszek Swirski]

On Mon, Sep 4, 2023 at 4:28 PM Iurii Zamiatin <iurii.z...@arm.com> wrote:

1) Are there any plans to add additional testing infrastructure for Maglev? Given that codegen for some nodes is quite complicated, it could be beneficial to test code for some of the nodes in isolation.

We're very much interested in ideas for better testing, if you have a good way of testing nodes in isolation I'd be more than glad to hear them.

 

2) With respect to folding, are there any plans to replace nodes with more specialized counterparts (e.g. how this comment suggests)?

It's definitely a possibility, but not a certainty. It's not clear whether it's better to do optimisations like this on an node replacement level or a GenerateCode level, when the number of nodes emitted stays roughly the same -- in particular for things like constants, we've so far made pretty ad-hoc decisions around whether to do the constantness check in GenerateCode (like is_little_endian_input in LoadSignedIntDataViewElement) or do emit a different node for known constants (like the comment you linked suggests).

 

3) If we can significantly improve performance by moving one of the GenerateCode methods out of the "maglev-ir.cc" file into an architecture-specific folder, what is the best way to incorporate these changes?

Depending on what you'd want to do, my preference would be to try to improve the performance by adding architecture-specific logic to the MaglevAssembler (maybe with higher-level operations) and keeping GenerateCode arch-independent, so that the optimisations could be reused, but it's a bit of a judgement call. I'd be interested to hear the specific case you're thinking of.

[Iurii Zamiatin]

Great, thanks for the tips.

> I'd be interested to hear the specific case you're thinking of.

Nothing at the moment, we just wanted to know what is the best strategy moving forward.