On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie <i...@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
> <sviswanat...@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
