RFR: 8264188: Improve handling of assembly files in the JDK

[David Holmes]

On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. 
> 
> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. 
> 
> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. 
> 
> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. 
> 
> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form
> # if (a) {
> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`).
> 
> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-().
> 
> This patch has been partly written by Sandhya Viswanathan <sviswanathan at openjdk.org> for the panama-vector repo.

Hi Magnus,

The renaming seems reasonable to me, but I think these files are of most interest to the compiler folk so I've added hotspot-compiler-dev to the cc list.

Can't comment on the build changes in detail - they seem reasonable other than Erik's queries about selecting 32-bit versus 64-bit based on the host or the target. I'm assuming the host must be 64-bit to build for 64-bit.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/3198