On 9/15/23 09:35, Derick Rethans wrote:
This is a lot of new code, that very few other people understand in great detail.I think it is unwise if we have another large part of the engine that does not have enough people understanding enough of it, to be able to debug issues, and contribute to its continued development.
Agreed.Additionally, despite the use of a Git submodule complicating things for "everyone else," it provides a clear dependency and development boundary, avoiding situations where the php-src version of IR drifts from the upstream version. I think we can adjust tooling and messaging to help folks know how to use the submodule. :-)
As such, I don't think this should just be merged, without a comprehensive document explaining what it is, how it works, what pitfalls there are, etc. The natural process that we have for PHP would be to create an RFC. An RFC should also include a user-facing API on how to configure, and enable, the JIT and its optimisations, as our current implementation it is not the most convenient for users. I understand that working on an RFC for such a complex issue is going to take time, but that also gives to opportunity to pair with somebody, who, while writing it, will also learn how it works. That would also ready improve the debugging/contributing issues.
+1, this needs an RFC, if only to help articulate and explain how it works, as Derick says. I'd love to volunteer to help with the RFC, but I'm already stretched thin, as it is.
Separately, I am not sure why your PR couldn't just replace the JIT that we already have? It would IMO not make sense to have two different ones at the same time.
This was my thought, as well. A few things I noted while looking through the code in the IR repository...It looks like the goal of the project is for IR to provide JIT compilation for other projects. Do you already have some idea where (other than php-src) it will be used? Is it already being used elsewhere?
IR is currently on your personal GitHub account, but the copyright listed on the license is for "Zend by Perforce," while other source files (e.g., ir_cpuinfo.c) list "IR project" as the copyright holder. I assume this is because you (Dmitry) have been working on this on Zend's time, while other contributors have been working on it independently. Who is the ultimate owner/controller of the project? If it's a Zend by Perforce project, what's their goal for it? (I'm not asking because I think there are hidden agendas; I'm just curious what the plans are for long-ish term support of IR.)
Noted that the license on IR is MIT. Love it! Cheers, Ben
OpenPGP_signature
Description: OpenPGP digital signature
