[PATCH] D140959: RFC: Multilib prototype

[Michael Platings via Phabricator via cfe-commits]

michaelplatings added a comment.

How the multilib system matches user arguments is the main problem I've been struggling with.

These are the options I see:

1. Grant the multilib system full access to all cc1 arguments, as demonstrated by the current code. However declare the multilib system unstable - if you write a multilib specification, you are responsible for making sure it's updated when clang is updated. Clang plugins set the precedent for such an approach.

  Advantage: It's powerful.

  Disadvantages:
  - Experience with clang plugins suggests instability will be a source of frequent pain.
  - @lenary points out that the order of arguments can be significant.
  - Requires some major refactoring of how arguments are processed before this can be done in a robust way (how I implemented it in the prototype is far from robust).

2. Pass to the multilib system only the arguments as provided by the user.

  Advantage: Greatly reduced API surface.

  Disadvantage: whoever writes a multilib specification will have to reinvent a lot of logic to infer attributes from --target, -march, -mcpu etc. but with inadequate tools to do so.

3. Normalise user arguments before passing them to the multilib system.

  Advantages:
  - Uses the existing arguments API.
  - Powerful, if it can be done correctly.

    Disadvantage:
  - The normalisation process effectively becomes a new API.
  - Normalisation appears hard to do correctly = likelihood of bugs.
  - Identifying attributes from arguments is fiddly e.g. extracting Arm architecture extensions from the march argument.
  - It's too easy to write a regex that could unintentionally match a newly introduced argument so the instability problem remains somewhat.

4. Hard-code the attributes and how they are detected in the same way they already are right now. For Arm this could be extended with Function Multi Versioning as @lenary pointed to, with namespacing to avoid potential clashes with other names. So you could have attributes like `[fsanitize=address, fno-exceptions, mfloat-abi=softfp, march=thumbv8.1m.main, arm:mve]`.

  Advantages:
  - This is similar to what we already do for multilib so it's well understood.
  - Limited yet extensible API.

    Disadvantages:
  - Greatly limits the expressiveness of the multilib system.
  - Any time someone wants to base their multilib on a new attribute it requires a change to Clang.
  - Some regular expressions still required for forward compatibility e.g. with future versions of Armv8-M.

5. A combination of (1) and (4) as proposed by @lenary.

  Advantages:
  - Stability where predefined attributes are available.
  - The power to access unstable arguments if necessary.

    Disadvantages:
  - Same as for (1) - requires some major refactoring of how arguments are processed before this can be done in a robust way (how I implemented it in the prototype is far from robust).
  - Greater maintenance burden.

None of these options are great but (4) is low risk and extensible so I'm currently investigating that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140959/new/

https://reviews.llvm.org/D140959