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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
