Repository navigation
Conversation
This patch specifies additional features for FMV, mostly focused on codegen and also for features recently bumped to beta.
| | `FEAT_SME_F16F16` | sme-f16f16 | ```ID_AA64SMFR0_EL1.F16F16 == 0b1``` | | ||
| | `FEAT_SME_F8F16` | sme-f8f16 | ```ID_AA64SMFR0_EL1.F8F16 == 0b1``` | | ||
| | `FEAT_SME_MOP4` | sme-mop4 | ```ID_AA64SMFR0_EL1.SMOP4 == 0b1``` | | ||
| | `FEAT_LSE2` | lse2 | ```ID_AA64MMFR2_EL1.AT >= 0b0001``` | |
There was a problem hiding this comment.
I am wondering if we should drop this feature for now. Do you have a use case for it?
There was a problem hiding this comment.
Yes this feature is used to allow STP and LDP instructions to be used for 128-bit atomics.
There was a problem hiding this comment.
LSE2 is not something modeled in GCC architecture flags so this would only be a dispatch feature for us, there would be no code gen change.
I would probably lean towards not including it as a personal preference.
There was a problem hiding this comment.
So how does GCC work for 128-bit atomics ? It never makes use of STP and LDP even if present or is the LSE2 enabled by other flag ?
There was a problem hiding this comment.
We talked about it a bit internally and it turns out we use ifuncs in libatomic, so that's a pretty clear argument that we should do this. We need to look into adding a march flag in GCC as well.
My next comment goes doubly so then, I think it is unlikely we will be able to do the work required for lse2 at this point.
There was a problem hiding this comment.
Sorry I am not sure I quite understood you comment. It seems like you are suggesting that at some point supporting lse2 codegen will be necessary by GCC ? If that's the case, isn't it the argument for multiversioning this feature so users will be able to make use of that codegen using FMV ? I understand you cannot support it now, but LLVM can and since FMV is versioned you could just advertise older version to users so they don't expect GCC support for these and bump it once you add it. Or am I missing smth ?
There was a problem hiding this comment.
Yes sorry I was unclear. That's what I mean. I was incorrect previously and I agree there is a case for LSE2 GCC (and we should add march flags for it)
But as this will be difficult in GCC I would prefer to have the FMV suport integer be incremented for this PR so we can differentiate to users if the previous FMV features make GCC 17 but LSE2 does not.
| | sme-f16f16 | 202690 | | ||
| | sme-f8f16 | 202690 | | ||
| | sme-mop4 | 202690 | | ||
| | lse2 | 202690 | |
There was a problem hiding this comment.
I think it would be safer to bump the version number for these. There's a possibility the previous ones make GCC 17 but these dont (depending on how much time I have).
| | `FEAT_SME_F16F16` | sme-f16f16 | ```ID_AA64SMFR0_EL1.F16F16 == 0b1``` | | ||
| | `FEAT_SME_F8F16` | sme-f8f16 | ```ID_AA64SMFR0_EL1.F8F16 == 0b1``` | | ||
| | `FEAT_SME_MOP4` | sme-mop4 | ```ID_AA64SMFR0_EL1.SMOP4 == 0b1``` | | ||
| | `FEAT_LSE2` | lse2 | ```ID_AA64MMFR2_EL1.AT >= 0b0001``` | |
There was a problem hiding this comment.
LSE2 is not something modeled in GCC architecture flags so this would only be a dispatch feature for us, there would be no code gen change.
I would probably lean towards not including it as a personal preference.
This branch has not been deployed
3 participants
This patch specifies additional features for FMV,
mostly focused on codegen and also for features
recently bumped to beta.