rsandifo-arm added a comment. I can see at least three ways of handling this:
1. @paulwalker-arm's suggestion to allow `-march=` without a base architecture (or with a dummy base architecture that means “no change”) 2. a single new option `-mfoo=` that applies on top of `-march` and can be used to add or remove architecture features 3. individual `-m` and `-mno-` options for each ISA feature. I think all three achieve the same objective. I assume for (1) that `-march=` options would apply in-order, so that an `-march=` without a base architecture would apply on top of any previous `-march=`, whereas an `-march=` with a base architecture would override all previous `-march=` options (both old-style and new-style). This behaviour might be an advantage in some situations and a disadvantage in others. Build systems would need to be careful about where in the command line the extra features go (but most probably are). For (2) we could say that all `-mfoo=` options apply (cumulatively, in order) to the final `-march` option, even if the `-march` option comes later than some of the `-mfoo=` options. This too could be an advantage in some situations and a disadvantage in others (as a reversal of the situation for (1)). The architecture can already be set by two options rather than one: `-march=` and `-mcpu=`. Currently (at least in GCC), `-march=` trumps the architecture effects of `-mcpu=`, even if `-mcpu=` is specified after `-march=`. I suppose the difficulty for (1) is then deciding what should happen if an `-march=` without a base architecture is specified alongside an `-mcpu=`. Does the `-march=` option apply to the `-mcpu=` choice of architecture even if the `-mcpu=` appears later? If so, `-march=` options without a base architecture would sometimes have a cumulative effect with later (`-mcpu=`) options as well as earlier (`-march=` or `-mcpu=`) ones. This might be non-intuitive and would be another way in which `-mcpu=` is not exactly equivalent to the associated `-march=` and `-mtune=` options. So perhaps one advantage of (2) over (1) is that the semantics are easier to describe. `-mfoo=` options apply cumulatively to the command line's final choice of base architecture, however that choice is specified. Personally I'm not very keen on (3). Reasons: - (1) and (2) collect the (subtle) semantics about option precedence in a single place. (3) distributes it among many individual options. - There are a lot of supported ISA features, so there would be a lot of `-m` and `-mno-` options to document. It would become harder to separate out `-m` options related to architecture selection from `-m` options that do other things. - With (3) it becomes much harder to check that every supported feature has an associated option. With (1) and (2) this would be guaranteed by construction. - The `+feature` and `+nofeature` style is also used in things like `#pragma GCC target`, which is another mechanism for changing ISA features without changing the base architecture. It feels like the new options are equivalent to sticking such pragmas at the start of the translation unit, so it would be good for them to use a consistent style. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113779/new/ https://reviews.llvm.org/D113779 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
