[Products] Don't dlopen libraries built for an incompatible ISA

[giordano]

Exactly same thing as JuliaPackaging/BinaryBuilder.jl#1194 (which will eventually be based on this PR). I still need to add tests, once I figure out how platforms_match is supposed to compare platforms.

At least I verified that with this PR and the one in BB I can build a library for AVX512 on an AVX2 system, without audit freaking out.

[vchuravy]

I am not sure I would call this march. llc has mcpu which has names like opteron or x86-64-v3 and mattr which allows you to set feature sets.

avx is the name of a feature set. I think following hwcaps/linux feature level and only support:

x86-64-v1
x86-64-v2
x86-64-v3
x86-64-v4

Might be the best.
x-ref: JuliaLang/julia#42073

The logic for how to map x86-64-v3 to different compilers is defined here https://github.com/archspec/archspec-json/blob/020e418c9fe991a8155e53245fde4e4bdef08382/cpu/microarchitectures.json#L135-L191

[giordano]

He, those names and sets are in Base: https://github.com/JuliaLang/julia/blob/c50361144ce783cecf65294e09d6e7cfdc73eb3f/base/binaryplatforms.jl#L598 changing them is quite a nightmare

[giordano]

...Unless you're going to suggest to move the dictionary to https://github.com/JuliaPackaging/Yggdrasil/blob/master/platforms/microarchitectures.jl

[vchuravy]

:/ How are we going to deal with adding new names? E.g. power9? I would prefer for these not to be dependent on Julia releases. So yes moving them there or MicroArchitectures.jl (better than JLLWrappers?) would be nice.

[giordano]

I think we still depend on julia for features detection (and for powerpc that's completely missing).

[giordano]

To be clear, what name do you suggest instead of march? I think we initially thought about microarchitecture but that was a bit mouthful.

I'm also mostly ok with revising the levels we have (especially if we move them to https://github.com/JuliaPackaging/Yggdrasil/blob/master/platforms/microarchitectures.jl so we don't need to worry about compatibility), but we'll also need to revise all the compiler flags and versions in

BinaryBuilderBase.jl/src/Platforms.jl

Lines 90 to 147 in 55c795d

	# NOTE: This needs to be kept in sync with `ISAs_by_family` in `Base.BinaryPlatforms.CPUID`
	# This will allow us to detect these names at runtime and select artifacts accordingly.
	const ARCHITECTURE_FLAGS = Dict(
	# Many compiler flags are the same across clang and gcc, store those in "common"
	"common" => Dict(
	"i686" => OrderedDict(
	"pentium4" => ["-march=pentium4", "-mtune=generic"],
	"prescott" => ["-march=prescott", "-mtune=prescott"],
	),
	"x86_64" => OrderedDict(
	# Better be always explicit about `-march` & `-mtune`:
	# https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/
	"x86_64" => ["-march=x86-64", "-mtune=generic"],
	"avx" => ["-march=sandybridge", "-mtune=sandybridge"],
	"avx2" => ["-march=haswell", "-mtune=haswell"],
	"avx512" => ["-march=skylake-avx512", "-mtune=skylake-avx512"],
	),
	"armv6l" => OrderedDict(
	# This is the only known armv6l chip that runs Julia, so it's the only one we care about.
	"arm1176jzfs" => ["-mcpu=arm1176jzf-s", "-mfpu=vfp", "-mfloat-abi=hard"],
	),
	"armv7l" => OrderedDict(
	# Base armv7l architecture, with the most basic of FPU's
	"armv7l" => ["-march=armv7-a", "-mtune=generic-armv7-a", "-mfpu=vfpv3", "-mfloat-abi=hard"],
	# armv7l plus NEON and vfpv4, (Raspberry Pi 2B+, RK3328, most boards Elliot has access to)
	"neonvfpv4" => ["-march=armv7-a", "-mtune=cortex-a53", "-mfpu=neon-vfpv4", "-mfloat-abi=hard"],
	),
	"aarch64" => OrderedDict(
	# For GCC, see: <https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html>. For
	# LLVM, for the list of features see
	# <https://github.com/llvm/llvm-project/blob/1bcc28b884ff4fbe2ecc011b8ea2b84e7987167b/llvm/include/llvm/Support/AArch64TargetParser.def>
	# and
	# <https://github.com/llvm/llvm-project/blob/85e9b2687a13d1908aa86d1b89c5ce398a06cd39/llvm/lib/Target/AArch64/AArch64.td>.
	# Run `clang --print-supported-cpus` for the list of values of `-mtune`.
	"armv8_0" => ["-march=armv8-a", "-mtune=cortex-a57"],
	"armv8_1" => ["-march=armv8.1-a", "-mtune=thunderx2t99"],
	"armv8_2_crypto" => ["-march=armv8.2-a+aes+sha2", "-mtune=cortex-a76"],
	"a64fx" => ["-march=armv8.2-a+aes+sha2+fp16+sve", "-mtune=a64fx"],
	),
	"powerpc64le" => OrderedDict(
	"power8" => ["-mcpu=power8", "-mtune=power8"],
	# Note that power9 requires GCC 6+, and we need CPUID for this
	#"power9" => ["-mcpu=power9", "-mtune=power9"],
	# Eventually, we'll support power10, once we have compilers that support it.
	#"power10" => ["-mcpu=power10", "-mtune=power10"],
	)
	),
	"gcc" => Dict(
	"aarch64" => OrderedDict(
	"apple_m1" => ["-march=armv8.5-a+aes+sha2+sha3+fp16fml+fp16+rcpc+dotprod", "-mtune=cortex-a76"],
	),
	),
	"clang" => Dict(
	"aarch64" => OrderedDict(
	"apple_m1" => ["-march=armv8.5-a+aes+sha2+sha3+fp16fml+fp16+rcpc+dotprod", "-mtune=apple-a12"],
	),
	),
	)

which I wasn't exactly looking forward to 😁 Side note, I'm moderately sure we settled on the sets we now have in Julia Base before the glibc x86-64 levels were widely advertised 😉

[vchuravy]

I think march is fine, I am more opposed to calling avx a micro-architecture since it is not, but a micro-architecture feature.

Yeah which is why I pointed out archspec, we could parse that JSON instead of maintaining the same thing in BB.