[flang] Add Solaris/x86 support to Optimizer/CodeGen/Target.cpp

[ro]

Summary

When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests FAILed with

error: /vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310: not yet implemented: target not implemented

This patch fixes that for Solaris/x86, where the fix is trivial (just handling it like the other x86 OSes).

Tested on amd64-pc-solaris2.11; only a single failure remains now.

There are a couple of issues, though:

• All the specializations of GenericTarget claim in their comments to be Linux-specific, but with the exception of ppc64le they are used for several other OSes as well.
• The cases in fir::CodeGenSpecifics::get should be sorted, but aren't.
• While Solaris/SPARC has the same issue, there's currently no SPARC support at all. I'll have to figure out how to do this. There's a comment in gcc/config/sparc/sparc.cc (Functions for handling argument passing) describing the ABI for complex args and return values. The SPARC and SPARC V9 ELF psABIs don't include this.

[rovka]

You're right that support for various OSes/targets is incomplete or missing in flang. I think it's ok to let Solaris through here if you're interested in supporting it, as it allows you to have a build of flang that you can experiment with. At the moment, code generation support is considered experimental in flang and not enabled by default, so this shouldn't cause innocent users any headaches.
Are you planning to enable flang on a Solaris buildbot?

[ro]

In D131054#3715140, @rovka wrote:

Are you planning to enable flang on a Solaris buildbot?

Not yet: I've been struggling to get the Solaris buildbots (both sparcv9 and amd64) reliably green for a long time. Right now I'm almost there, but adding flang/mlir to the mix would be a considerable throwback:

With this patch applied, there are two remaining FAILs on Solaris/amd64:

Failed Tests (2):
  MLIR :: Dialect/Math/canonicalize.mlir
  flang-OldUnit :: Evaluate/folding.test

However, Solaris/sparcv9 is way worse: it needs the SPARC equivalent of this patch (still WIP), D131151 which is still unreviewed, and still has quite a number of FAILs on top of that.

Until those are resolved, enabling flang in the buildbots would be a disservice, I believe, although it would certainy help to catch issues early rather than only discovering them during the release cycle.

flang/lib/Optimizer/CodeGen/Target.cpp

default:
     break;
   case llvm::Triple::ArchType::x86:
     switch (trp.getOS()) {
     default:
       break;
     case llvm::Triple::OSType::Linux:
     case llvm::Triple::OSType::Darwin:
     case llvm::Triple::OSType::MacOSX:
+    case llvm::Triple::OSType::Solaris:
     case llvm::Triple::OSType::Win32:
       return std::make_unique<TargetI386>(ctx, std::move(trp),
                                           std::move(kindMap));
     }
     break;
   case llvm::Triple::ArchType::x86_64:
     switch (trp.getOS()) {
     default:
       break;
     case llvm::Triple::OSType::Linux:
     case llvm::Triple::OSType::Darwin:
     case llvm::Triple::OSType::MacOSX:
+    case llvm::Triple::OSType::Solaris:
     case llvm::Triple::OSType::Win32:
       return std::make_unique<TargetX86_64>(ctx, std::move(trp),
                                             std::move(kindMap));
     }
     break;
   case llvm::Triple::ArchType::aarch64:
     switch (trp.getOS()) {
     default: