Don't emit module metadata for non-toplevel modules.

[maleadt]

Instead, rely on the linker automatically inheriting the metadata from the parent module. This avoids warnings and aborts with external users such as GPUCompiler.jl.

[gbaraldi]

Looks fine to me. I guess our adhoc linker was fine with this but LLVMs default one complained?

[maleadt]

Yeah, IIUC another thing that landed as part of #57010.

[vtjnash]

The concept that there is a "parent module" seems unsound to me. Does your linker not handle these correctly? I'd expect the LTO linker we're using here to combine these properly.

[maleadt]

I'm not linking these, that happens as part of jl_emit_native calling jl_merge_module in a loop. And yeah LLVM's linker complains with warnings like:

warning: linking module flags 'Dwarf Version': IDs have conflicting values ('i32 4' from kernel with 'i32 2' from start)

... or an abort when there's a mismatch in stack-protector flags.

I considered alternative approaches, either (1) having the fresh modules in the jl_emit_native loop being clones of the initial llvmmod passed into it (which works for GPUCompiler.jl but isn't compatible with how precompilation invokes staticcompilation), and (2) adding additional flags to jl_new_ts_module to copy the flags from the llvmmod passed in (but that would result in those prototypes getting very complicated; simply omitting the "optional" metadata seemed more straightforward).

[vtjnash]

jl_new_ts_module to copy the flags from the llvmmod passed in

I think this option makes the most sense. In theory LLVM already implements it because it uses this same operation in many places. In practice, it isn't exactly optimal, but it is just CloneModule with a lambda that returns false, followed by a pass to remove all globals (alternatively, just copying out the 10 lines from that function which are relevant) as here: https://llvm.org/doxygen/namespacellvm.html#a61553b705fc9be3d8d0a18a8af1bc152