Hi Richard,
On 4/15/25 12:22, Richard Henderson wrote:
v2: 20250107080112.1175095-1-richard.hender...@linaro.org
v3: 20250216231012.2808572-1-richard.hender...@linaro.org
Since it has been 2 months, I don't recall specific changes from v3 to v4.
It's mostly application of r-b tags. There is one more patch, which I
believe was Phil asking for one patch to be split.
Patches still requiring review: 29, 41-43, 46, 47, 49-51, 55, 57, 59-62,
64, 66-68, 70, 72-78, 80, 82-87, 89, 91, 93, 95, 97-102, 104, 106-162.
r~
Thanks for this series Richard, reviewing this is a good opportunity to
look at register allocation and associated constraints in tcg.
The new way to define dynamic constraints is quite neat, and readable,
as it was one of the feedback you previously asked.
The only concern I have is that we could create silent "performance"
related bugs, where a specific feature is deactivated because of a bad
combination, but it's inherent to this approach and not a blocker.
Even though I reviewed this series, it's hard for me to review all the
target specific implementations, as I don't have your expertise on such
a wide range of architectures.
As a more general question, how do you approach testing for a series
like this one? I see two different challenges, as it touches the IR
itself, and the various backends.
- For the IR, I don't know how extensive our complete test suite is
(regarding coverage of all existing TCG ops), but I guess there are some
holes there. It would be interesting to generate coverage data once we
can get a single binary in the future.
- For the various backends:
* Are you able to compile QEMU on all concerned hosts and run testing
there?
* Or do you cross compile and run binaries emulated?
* Or another way I might ignore at the moment?
Regards,
Pierrick
