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.
On Tuesday, September 5, 2023 at 1:02:40 PM UTC+1 Leszek Swirski wrote: > 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 >> <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/maglev/maglev-graph-builder.cc;l=1695;drc=5d42230d2ae9adc9c0ebed6acea8c5896f04218e> >> >> 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. > -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/2d21cfeb-c0fc-4685-83bd-00fa1414c531n%40googlegroups.com.
