On 20/08/2020 05:48, Nick Gasson wrote:
> On 08/19/20 19:10 pm, Andrew Haley wrote:
>> On 19/08/2020 11:05, Magnus Ihse Bursie wrote:
>>> This is maybe not relevant, but I was surprised to find
>>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code,
>>> and b) the name implies that it is a test, even though that it resides
>>> in src. Is this really proper?
>>
>> I have no idea whether it's really proper, but it allows us to check
>> that instructions are encoded correctly by cross-checking with the
>> system's assembler. There might well be a more hygienic way to do
>> that, but I don't want to be without it.
>
> It is perhaps a bit strange to have the test code under src/ and
> embedded in the assembler implementation. How about we move it under
> test/ using the existing gtest framework for native code tests? That
> runs in tier1 and also for release builds. I tried this just now and
> it's easy to do.
I'm not sure that would be an improvement. This python code is used to
generate C code run as part of JVM startup in a debug JVM build i.e.
code that is linked into the JVM itself. So, the code it generates is
really the same as the debug code embedded in the JVM. It doesn't really
bear any relation to the code in the test tree.
If the generator code were to go anywhere else it would perhaps make
most sense to put it in the make tree. I'm not sure that is required
though or even appropriate. There is already a precedent for keeping
generator code in the source tree and, when it is specific to a given
arch, keeping it next to the related source. The adlc generator code
sits in the shared source tree. The m4 file used to generate parts of
aarch64.ad is in the aarch64 source tree.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
