[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

DavidSpickett added a comment. For (1) and (2) is there a need to be able to reset the architecture setting no matter the previous `march` and `` are? Currently we're talking about *not* wanting having to use `-march=armv8-a+crc` but would you still want a way to reset the architecture no

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. In D113779#3496589 , @fhahn wrote: > In D113779#3207936 , @SjoerdMeijer > wrote: > >>> If anybody has contacts to GCC that would be very helpful. Unfortunately I >>> don't think I

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

scanon added a comment. 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn updated this revision to Diff 458407. fhahn added a comment. 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 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. Herald added a subscriber: MaskRay. Herald added a project: All. In D113779#3207936 , @SjoerdMeijer wrote: >> If anybody has contacts to GCC that would be very helpful. Unfortunately I >> don't think I will be able to drive this.

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. > If anybody has contacts to GCC that would be very helpful. Unfortunately I > don't think I will be able to drive this. Ok, I will bring this up internally first with some folks that work on GCC and see what happens. To be continued... Repository: rG LLVM

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. In D113779#3192009 , @SjoerdMeijer wrote: > 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. 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. If others also think this makes sense, then here a few

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. 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`. Repository: rG LLVM Github Monorepo

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

manojgupta added a comment. > 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. In D113779#3130853 , @paulwalker-arm wrote: > 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

manojgupta added a comment. Yes, the current approach of "-march=+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. Any additive or subtractive alternative is welcome.

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

paulwalker-arm added a comment. 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. In D113779#3130744 , @DavidSpickett wrote: > There was a similar proposal for crypto https://reviews.llvm.org/D60472. > > Quoting @manojgupta for the pitch for that: > >> The motivation for this change is to make "crypto" setting

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

DavidSpickett added a comment. (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) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113779/new/

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

DavidSpickett added subscribers: manojgupta, DavidSpickett. DavidSpickett added a comment. There was a similar proposal for crypto https://reviews.llvm.org/D60472. Quoting @manojgupta for the pitch for that: > The motivation for this change is to make "crypto" setting an additive option > e.g.

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn added a comment. In D113779#3130701 , @SjoerdMeijer wrote: > 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. 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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

fhahn created this revision. fhahn added reviewers: aemerson, ab, dmgreen, SjoerdMeijer, scanon. Herald added subscribers: dang, kristof.beyls. fhahn requested review of this revision. Herald added a project: clang. This patch adds support for `-m[no]fpf16`, ` `-m[no]fpf16fml` and `-m[no]dotprod`