Differential D113779
[Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features. Authored by fhahn on Nov 12 2021, 9:05 AM.
Details
This patch adds support for -m[no]fpf16, -m[no]fpf16fml` and The flags behave similar to specifying an -march flag with
Diff Detail
Unit Tests
Event TimelineComment Actions This introduces another way of setting (optional) architecture extensions and having two ways to do the same is nearly always a bad thing, which is how one of my colleagues phrased it. This was already a complex area and thus I don't think introducing another is going to really simplify things. This is the main problem of this proposal. Other things are:
More subjective: for most users this whole -march business is abstracted away in build systems, so they won't have to deal with this, that's why this isn't so much of an improvement. If we want a better user experience set options, there are probably other things that are more important, like checking legal/illegal architecture combinations. So, in summary, we prefer not to go ahead with this. And the precedent that was mentioned, -mcrc, should probably be deprecated. Comment Actions I think there's a subtle difference to using the -mXXX options vs -march. -mXXX adds a feature *without* changing the default architecture version. Unless I am missing something, it's not possible to selectively add target features using -march without also forcing the architecture version to some particular version. AFAICT the only alternative to -mXXX options would be using -Xclang -target-feature -Xclang +dotprod, which is very verbose and not documented. The -mXXX flags would allow users to conveniently write forward-compatible compiler invocations that also ensure a minimum set of features is available. Using -mXXX flags is very common on X86 and providing a similar interface for AArch64 will likely help users transitioning.
The -mXXX flags add the target feature to the list of target features, the same as additional features provided to -march. It should be equivalent to specifying extra flags via -march in terms of checking for invalid combinations and conflict resolution. Comment Actions There was a similar proposal for crypto https://reviews.llvm.org/D60472. Quoting @manojgupta for the pitch for that:
Concerns were raised there. Seems like we're balancing adding a bunch of (clang only for at least the short term) options versus making the build system(s) cope with having to track what the last -march was. Comment Actions (I should note that crytpo isn't the best example because it means different things to different base architectures, that part doesn't apply here) Comment Actions Thanks for sharing the related patch/discussion.
Please see my earlier response. There can be use cases where the build system may not know what the last -march was, because the user may not have specified an explicit -march (e.g. they want to use the default picked by the compiler). Is there a way for the build system to conveniently determine what the default architecture version of the compiler is? Also pushing this to the build system vendors means we need to convince X build-system vendors to adjust their implementations. Comment Actions Rather than adding connivence options after the fact what about allowing -march= to be specified multiple times? The first must be the usual format with later ones required to start with +. The defined parsing behaviour would be as if there was a single -march instance positioned at the first occurrence but containing the value of all instances when combined from left to right. For example -march=armv8.4-a ...... -march=+nofp16 or perhaps += syntax like -march=armv8.4-a ...... -march+=nofp16+nosve is more intuitive? Comment Actions Yes, the current approach of "-march=<isa>+feature" is terrible and does not work with developers who want flexibility of features. This being pitched as a feature imo is akin to promoting a design bug as a feature. Comment Actions I think that would be a convenient option which wouldn't require us to add a lot of new options, which would be quite cumbersome. But to address the main issues (providing a purely additive way to specify features) I think we would need to allow -march=+feature, without any preceding -march=armvXXX. I wouldn't go so far as to call the current -march handling terrible, but I think there are valid use cases that cannot be addressed with it, as per the current discussion. As you said, providing some way specify features additively without also committing to a specific architecture version would be desirable for our users IMO. Comment Actions
I'd argue the contrary that the current way of -march=isa+feature is broken. I am yet to see a build system that understands or processes the values inside march arguments. And this blocks users from choosing custom hw features without resorting to terrible hacks. Comment Actions ping :) Any additional thoughts? Since the original concerns were raised both @manojgupta and myself tried to share a bit of additional background on the motivation and to clarify the difference between -mXXX and -march. Comment Actions Ok, fair enough, perhaps adding features is a valid use-case. I will refrain from commenting on "things are terribly broken". I agree it is broken, but in a different way than suggested in previous comments.
Comment Actions Agreed.
This would be the easiest way to implement this, *but* it would require either to allow not specify an architecture version with -march (which seems a bit odd) or perhaps adding a default architecture version which just uses the default set. For our users, either would work, so I'd be happy to go with what seems most compelling to others. But compatibility with X86 is IMO also valuable for people porting from X86->AArch64.
If anybody has contacts to GCC that would be very helpful. Unfortunately I don't think I will be able to drive this. Comment Actions
Ok, I will bring this up internally first with some folks that work on GCC and see what happens. To be continued... Comment Actions Rebase and ping :) The potential benefit of having -m flags is also mentioned in this recent bug report: https://github.com/llvm/llvm-project/issues/57588 Comment Actions Wearing my compiler user hat, I would much rather use additive -mfeature than have to specify these as -march+feature, even when using a build system that nominally handles this stuff, because I frequently want to be able to compile one specific file with "whatever the prevailing options are, but also enable this one feature." Most build systems make this possible somehow (track down the arch variable, append +feature to it, etc), but it's considerably simpler if you can just append -mfeature to the list of flags and call it a day. Comment Actions Sorry for the delay. I have just left a message for our GNU toolchain guys with an invitation to add comments here. Comment Actions I can see at least three ways of handling this:
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:
Comment Actions For (1) and (2) is there a need to be able to reset the architecture setting no matter the previous march and <new extension options> are? That said, applying the extra extensions to the last -march gives you a way to bump the base architecture which could be useful. -march=armv8-a -add-extension=+crc -march=armv8.4-a => armv8.4-a+crc. For (3) I agree with your concern.
A rough count: $ clang --help | grep " \-m" | wc -l 108 I also wouldn't want to get into a situation where we name an extension such that -mextension looks more like it's a general compiler option. E.g. -mnvj Enable generation of new-value jumps "nvj" isn't far off what our extensions end up being called. |