User Details
- User Since
- May 1 2018, 4:00 AM (217 w, 3 d)
Mar 16 2022
This approach looks good to me FWIW. The main advantages as I see it are:
- Treating PSTATE.SM and PSTATE.ZA as orthogonal to the set of implemented features follows the scheme used in the ISA specification, so it's easy to cross-check the two. The IsSVEEnabled review comment is an example of this.
- It is likely to cope better with any future extensions to SVE or SME: the streaming-compatible, streaming and non-streaming subsets of each ISA extension would not need to be identified individually on the command line or in IR. Or to put it another way: requiring multiple +streaming-foo flags (and so repeating the “streaming”) feels like specifying the same bit of information multiple times.
- It avoids the risk of combinatorial explosion if we ever need to do something similar for another degree of freedom.
Oct 19 2021
Sorry to ask about an already-closed ticket, but: it looks like this makes the register unconditionally available, rather than making it conditional on FeaturePerfMon. Is that the intended behaviour? GNU as does still require v8.4 for this register.
Jun 3 2021
Thanks for the fix. I agree this is the right behaviour FWIW. I held off approving it in case there's another idiom that's preferred when comparing canonical types.
Jan 11 2021
Jan 8 2021
Ping. Also, please let me know if the response above doesn't answer the concerns and if you'd like more info/justification.
Dec 21 2020
Thanks for the reviews.
Dec 18 2020
Ping.
Dec 7 2020
Nov 27 2020
Sorry for reviving this after so long, but I'd like to bump it from an RFC to an RFA. As the new covering message says, the spec is now part of the ACLE specification.
Rebase onto current trunk, and also on top of:
https://reviews.llvm.org/D92222
Was superceded by later revisions, but I forgot to close this one.
Was superceded by later revisions, but I forgot to close this one.
Nov 12 2020
Nov 11 2020
The tests look good to me FWIW. The Sema side is already covered by Sema/attr-arm-sve-vector-bits.c and the patch seems to test for the important ABI bits.
Aug 28 2020
Aug 21 2020
Aug 20 2020
LGTM from a spec point of view, but I don't think I should be the one to approve.
I'm not qualified to review the CodeGen stuff (or accept the patch, obvs. :-)) but FWIW, here are some comments on the doc and Sema side.
Aug 19 2020
Aug 18 2020
LGTM, but I don't think I should be the one to accept.
Aug 13 2020
Thanks the update, the idea looks good in general. Two questions though:
- Is it worth having two functions? I thought it might be simpler to have just getCustomEHPadPreservedMask(), with nullptr meaning “no clobbers”.
- It looks from the tests like the function isn't saving or restoring z8-z23 and p4-p15, is that right? That's fine for landing pads that can't return directly to the callee (e.g. because they rethrow). But in these tests the landing pad does return to the caller. Since the extra callee-saved registers are clobbered on the EH edge, we need to save and restore those registers ourselves on control paths that include an EH edge and a return.
Aug 12 2020
Aug 4 2020
Jul 31 2020
Jul 27 2020
Jul 16 2020
Thanks for doing this. FWIW, the patch LGTM from a spec point of view. I just saw one minor spelling nit.
May 7 2020
May 6 2020
May 5 2020
Put two other related warnings under the new option
OK, thanks! Reclaiming and reopening the revision in that case.
May 4 2020
OK, I'll leave the file as-is in that case.
May 1 2020
I'd like to promote this from an RFC to an RFA. The associated cfe-dev discussion was:
Don't refer to the sizeless types as "scalars"
Mar 31 2020
Require operators to be defined as static or inside a namespace