[llvm] [SPARC][IAS] Add v8plus feature bit (PR #101367)

[via llvm-commits]

================
@@ -21,11 +21,16 @@ using namespace llvm;
 namespace {
   class SparcELFObjectWriter : public MCELFObjectTargetWriter {
   public:
-    SparcELFObjectWriter(bool Is64Bit, bool HasV9, uint8_t OSABI)
+    SparcELFObjectWriter(bool Is64Bit, bool IsV8Plus, bool HasV9, uint8_t OSABI)
         : MCELFObjectTargetWriter(
               Is64Bit, OSABI,
-              Is64Bit ? ELF::EM_SPARCV9
-                      : (HasV9 ? ELF::EM_SPARC32PLUS : ELF::EM_SPARC),
+              Is64Bit
+                  ? ELF::EM_SPARCV9
+                  // Note that we still need to emit an EM_SPARC32PLUS object
+                  // even when V8+ isn't explicitly requested, if we're
+                  // targeting a V9-capable CPU. This matches GAS behavior upon
+                  // encountering any V9 instructions in its input.
+                  : ((IsV8Plus || HasV9) ? ELF::EM_SPARC32PLUS : ELF::EM_SPARC),
----------------
koachan wrote:

Yep, I'm pretty sure of that. GCC does not control object type, GAS does, and what it does is autoselecting the object type to emit based on the contents of the asm file given to it, defaulting to EM_SPARC if no V9 instructions are encountered.

For example, a file containing just an empty function `void empty() {}` becomes a `retl; nop` in assembly, and since the resulting asm is free from V9 instructions, GAS will emit an EM_SPARC object, even if you specify `-mv8plus` in GCC.
On the other hand, something like `void fadd(std::atomic<int> v) { v++; }` will compile down to a `cas`, and given that `cas` is a V9 instruction, GAS will emit an EM_SPARC32PLUS object anyway even if you specify `-mno-v8plus` in GCC.

https://github.com/llvm/llvm-project/pull/101367