Warn when --iree-llvmcpu-target-cpu defaults to "generic".

[ScottTodd]

Progress on #18561.

We have these high level flags (and MLIR attributes) controlling what code the llvm-cpu compiler target generates using LLVM:

• --iree-llvmcpu-target-triple
  • e.g. x86_64-pc-windows-msvc
  • See https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/TargetParser/Triple.h
• --iree-llvmcpu-target-cpu
  • e.g. znver2
• --iree-llvmcpu-target-cpu-features
  • e.g. +prfchw,-cldemote,+avx,+aes,+sahf,+pclmul,-xop,...

Some targets (x86 and riscv64) in LLVM can infer the "features" for a given "cpu" with the getFeaturesForCPU() functions. Other targets may be able to look up available features on the host via llvm::sys::getHostCPUFeatures(). Short of either of those, we must fall back to having users explicitly list the features they want the compiler to use.

If the target CPU and target CPU features are both omitted, we currently fall back to "generic", meaning no "features". This PR sends more warning information to stderr if that case is detected. We could go a step further and make the default case propagate an error through the compiler, requiring users to explicit set "host", "generic", a known cpu type, or a known list of features.

---

TODO

• Update docs (https://iree.dev/guides/deployment-configurations/cpu/, source: docs/website/docs/guides/deployment-configurations/cpu.md)
• Audit the repository and other projects for usage of --iree-hal-target-backends=llvm-cpu that is missing an explicit --iree-llvmcpu-target-cpu or --iree-llvmcpu-target-cpu-features
• Test the different code paths (manually or with lit tests / automation)

---

Debugging tips while working on this:

• Run with --debug-only=iree-llvm-cpu-target to see the computed LLVMTarget get logged
• Note that multiple code paths run this code, including CLI flags that build defaultOptions_ for getDefaultExecutableTargets() and getVariantTarget/loadFromConfigAttr that may come from already constructed IR. We want error handling for all of them.

[stellaraccident]

Thanks - I think that starting with warnings is a good way to flush this. Then have an easy thing to upgrade to an error.

[bjacob]

Thanks!

The warning message could helpfully dump a list of accepted CPU values for the target architecture.

At that point, passing the missing CPU flag would be so easy that you might as well mandate it, promoting this warning into an error. If a user is technical enough to specify a non-host target triple, and you do the work for them to look up the known CPUs for that target triple, they can be bothered to pick one. Then they can even choose to just pass generic (and the message may suggest so) if that's what they want. At least they will blame their own poor (command) line choices for bad performance.