RFR: 8352020: [CompileFramework] enable compilation for VectorAPI [v2]

[Emanuel Peter]

On Tue, 18 Mar 2025 06:56:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary_tests/compile_framework/examples/IRFrameworkWithVectorAPIExample.java line 45:
>> 
>>> 43: /**
>>> 44:  * This test shows that the IR verification can be done on code compiled by the Compile Framework.
>>> 45:  * The "@compile" command for JTREG is required so that the IRFramework is compiled, other javac
>> 
>> What about a `CompileFilework::invokeIRTest()` or something like that, that just additionally loads the `TestFramework` class somehow (for example just creating an instance or accessing a field etc., we could also provide an empty static method in `TestFramework.java` that can be called to minimize the overhead), would that work? Then we do not need to worry about adding `@compile` or figuring out why the IR test is not working.
>
> Maybe... but is this kind of magic really worth it? It would also mean that any `CompileFraework` test always compiles the `TestFramework`. And if we decide to do this, I think it would be a separate RFE, since I'm just copying from `test/hotspot/jtreg/testlibrary_tests/compile_framework/examples/IRFrameworkJavaExample.java` here ;)

FYI: the issue will probably get worse over time, as there may be more and more test-library parts that are not used in the JTREG test directly, but only in the CompileFramework compiled code. I currently have a test under development where I have to write this:

/*
 * @test
 * @summary Test the Template Library's expression generation for the Vector API.
 * @modules jdk.incubator.vector
 * @modules java.base/jdk.internal.misc
 * @library /test/lib /
 * @compile ../../../compiler/lib/ir_framework/TestFramework.java
 * @compile ../../../compiler/lib/generators/Generators.java
 * @compile ../../../compiler/lib/verify/Verify.java
 * @run driver template_library.examples.TestFuzzVectorAPI
 */

But I'm not sure which test libraries we should always load... maybe we can address this down the road, when it really becomes cumbersome for people, and we know more what we want?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24082#discussion_r2000365127