Consistently use two dashes for long command line options. (#9064)

This updates our usage of command line flags we control (MLIR flags and IREE flags) to use two dashes for long options. Short options (e.g. `-o module.vmfb`) and options for tools outside our control (e.g. `-fsanitize=address`) remain unchanged.

This is part of addressing a source of confusion explained in https://github.com/google/iree/issues/5931. Several of our tools have bad failure modes when receiving malformed flags (typos, extra spaces, overlooking implicit stdin, etc.). We can reduce the risk of user errors by being consistent across the project in how we use command line flags.

---

⚠ Bikeshedding ahead ⚠

### Rationale

In general (across tools, languages, and platforms), command line tools use a mix of _positional_ arguments and _keyword_ arguments. Positional arguments use no prefix like `-` or `--` and are parsed in the order they appear. Keyword arguments use some prefix (typically `-` or `--`) followed by the flag name then a separator (typically `=` or ` `) and then the value.

Within keyword arguments, there are also "short" and "long" options. Short options are usually one letter versions of long options, and sometimes multiple short options can be mixed together. For example, see https://man7.org/linux/man-pages/man1/tar.1.html and equivalent commands like
* `tar --create --verbose --file etc.tar /etc`
* `tar -c -v -f etc.tar /etc`
* `tar -cvf etc.tar /etc`

Not all tools follow that convention, and parsing can be made to be more forgiving, but internal consistency within a project is worth aiming for.

Other discussions:

* [What's the difference betwen the single dash and double dash flags on shell commands?](https://serverfault.com/questions/387935/whats-the-difference-betwen-the-single-dash-and-double-dash-flags-on-shell-comm)
* [What's the difference between one-dash and two-dashes for command prompt parameters?](https://superuser.com/questions/372203/whats-the-difference-between-one-dash-and-two-dashes-for-command-prompt-paramet)

---

This change was generated via a mix of regex find/replaces and manual review. See each commit for more details.
1780 files changed
tree: 12698298ddc2f828b788bf4754142b54224baaff
  1. .github/
  2. benchmarks/
  3. build_tools/
  4. compiler/
  5. docs/
  6. experimental/
  7. integrations/
  8. iree/
  9. llvm-external-projects/
  10. runtime/
  11. samples/
  12. third_party/
  13. .bazelignore
  14. .bazelrc
  15. .bazelversion
  16. .clang-format
  17. .gitignore
  18. .gitmodules
  19. .pylintrc
  20. .style.yapf
  21. .yamllint.yml
  22. AUTHORS
  23. BUILD.bazel
  24. CMakeLists.txt
  25. configure_bazel.py
  26. CONTRIBUTING.md
  27. LICENSE
  28. README.md
  29. WORKSPACE
README.md

IREE: Intermediate Representation Execution Environment

IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.

See our website for project details, user guides, and instructions on building from source.

Project Status

IREE is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!

Communication Channels

Related Project Channels

  • MLIR topic within LLVM Discourse: IREE is enabled by and heavily relies on MLIR. IREE sometimes is referred to in certain MLIR discussions. Useful if you are also interested in MLIR evolution.

Build Status

CI SystemBuild SystemPlatformArchitectureConfiguration / ComponentStatus
KokoroBazelLinuxx86-64kokoro status bazel/linux/x86-swiftshader/core
KokoroCMake & BazelLinuxx86-64 (swiftshader)Integrationskokoro status cmake-bazel/linux/x86-swiftshader
KokoroCMake & BazelLinuxx86-64 (turing)Integrationskokoro status cmake-bazel/linux/x86-turing
KokoroCMakeLinuxx86-64 (swiftshader)kokoro status cmake/linux/x86-swiftshader
KokoroCMakeLinuxx86-64 (swiftshader)asankokoro status cmake/linux/x86-swiftshader-asan
KokoroCMakeLinuxx86-64 (turing)kokoro status cmake/linux/x86-turing
KokoroCMakeAndroidarm64-v8aRuntime (build only)kokoro status cmake/android/arm64-v8a
KokoroCMakeBare Metalrisc-v-32Runtimekokoro status cmake/baremetal/riscv32
KokoroCMakeLinuxrisc-v-64Runtimekokoro status cmake/linux/riscv64
BuildkiteCMakeAndroidarm64-v8aRuntimebuildkite status iree-android-arm64-v8a
BuildKiteCMakeAndroidarm64-v8aRuntime Benchmarksbuildkite status iree-benchmark
BuildKiteCMakeLinuxx86-64Tracing + Standalone Runtimebuildkite status iree-build-configurations

Architecture Overview

IREE Architecture

See our website for more information.

Presentations and Talks

  • 2021-06-09: IREE Runtime Design Tech Talk (recording and slides)
  • 2020-08-20: IREE CodeGen: MLIR Open Design Meeting Presentation (recording and slides)
  • 2020-03-18: Interactive HAL IR Walkthrough (recording)
  • 2020-01-31: End-to-end MLIR Workflow in IREE: MLIR Open Design Meeting Presentation (recording and slides)

License

IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.