Raise an error for unsupported MARCH or JULIA_CPU_TARGET

[nalimilan]

Extend the existing check for ARCH and MARCH and also reject 'generic'.

See #27402.

[yuyichao]

Please reopen for 0.6. Master doesn't need this anymore.

[nalimilan]

Why? At the very least, generic needs to be added to the existing check.

[vtjnash]

Isn’t it still a valid target name on master? We want to avoid targeting i387, since the i387 gives incorrect answers and (iirc) the mode switch is also very expensive (and not just because it changes the ABI)

[yuyichao]

sse2 is always enabled on master on x86, no matter what you give it. generic is now ALWAYS a right target to specify on ALL architecture. generic and i686 are also translated into pentium4 on 32bit x86. Other x86 tagets won't be translated but the feature set is still correct (it just won't use the best scheduling model).

See also #21849 (comment).

[nalimilan]

Isn’t it still a valid target name on master? We want to avoid targeting i387, since the i387 gives incorrect answers and (iirc) the mode switch is also very expensive (and not just because it changes the ABI)

I thought you said at #27402 (comment) we should reject generic. AFAIK it's more or less equivalent to i386, isn't it? Though I shouldn't have added it to the MARCH check since it's not supported.

[yuyichao]

And as for the C code.

1. I don't think it matters that much for C/C++ code in this repo (openlibm's build system should make sure the right arch is used if it is not already)
2. We already have a check for that in the code https://github.com/JuliaLang/julia/blob/master/src/atomics.h#L8 (It was moved around and end up in a strange place but it's nontheless there)

we should reject generic

It's a 0.6 issue. We should also "reject" generic on master but it's already handled automatically in the code so that neither the build system nor the user compiling/specifying -C target need to worry about it anymore.

[nalimilan]

OK, great. Does checking defined(__SSE2__) allow the compiler to use these instructions? BTW, shouldn't we remove the now redundant lines from Make.inc on master?

It's kind of late to fix this on 0.6, but I've filed #27440 anyway.

[yuyichao]

Does checking defined(SSE2) allow the compiler to use these instructions?

Checking is just, well, checking that it's available. Depending on the compiler though, it actually doesn't mean sse is preferred over x87. #21742 (comment) (likely gcc specific iirc) Checking march in makefile doesn't help either though.

BTW, shouldn't we remove the now redundant lines from Make.inc on master?

Maybe.

Also note that,

and not just because it changes the ABI

is actually not the case. I'm pretty sure there aren't different x86 ABI depending on the availability of sse registers. Even on latest x86 processors, 32bit code will still return floating point values on the x87 stack.

[nalimilan]

Checking is just, well, checking that it's available. Depending on the compiler though, it actually doesn't mean sse is preferred over x87. #21742 (comment) (likely gcc specific iirc) Checking march in makefile doesn't help either though.

What I meant is that still checking MARCH could make sense since passing MARCH=pentium4 allows the compiler to use SSE instructions. Since we require them, we may as well use them in C/C++/Fortran code...

[yuyichao]

Hmm, I'm a little confused about what you are asking. In any case, the points areqn

1. On master, the JIT will always use the right feature set no matter what you ask. generic is even preferred since it's, well, generic across all architectures.
2. Since a long time ago (at lease 0.5), we have a check in the C/C++ code to make sure SSE2 is required and available in the runtime. Checking MARCH in makefile doesn't really improve anything on top of this for C/C++ code.
3. Neither makefile MARCH check nor C/C++ SSE2 check makes sure GCC actually uses SSE2 when it can. This is a GCC specific issue that's determined by -mfpmath. Anyone care about 32bit x86 binary enough could add that to the makefile though I highly doubt if it'll actually make a difference anywhere. We just don't have a lot of floating point operations in the runtime.

[nalimilan]

Yeah, not sure what I was thinking. Of course the defined(__SSE2__) check ensures people pass the correct compiler flags to enable SSE2, in which case these instructions can be used (I guess I shouldn't be doing two things at the same time 😁). Anyway, thanks for writing that summary, that can always be useful for reference.