mylai-mtk wrote: > There are intentional tradeoffs here, for the ABI, which should be made > carefully; in some cases, it might be the right tradeoff to reject > standard-compliant code. If you've considered it, I guess I won't object. I > can't find any discussion of it, though.
The reduction of unprototyped function types to prototyped no parameter function types is proposed by me in <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/434#issuecomment-2162159763>, which is accepted without much discussion/objection. I also proposed treating such usages as errors, but it looks like this part had not been taken into the spec. > With my psABI hat on, settling on an ABI that turns out to be wrong is my big > concern, but you can't find those corner cases until you try it at scale (and > that's speaking from experience where we've missed things in the past for > CHERI). This is probably the kind of thing that needs to be explicitly marked > as experimental and with no ABI forward-compatibility guarantees, but that > needs to be landed so that people can start actually using it and finding > where it falls down in the real world. (But that doesn't obviate proper code > review, the implementation should still be proper even if the ABI isn't > stable.) Agree. I'm pretty sure that the mangling scheme is not perfect, especially when applied to ancient C projects. With regard to forward-compatibility management, I think we can introduce versioning to Zicfilp psABI as well? (cf. Tag_RISCV_atomic_abi in `.riscv.attributes` section) @kito-cheng > Given the comparison with the AArch64 PAuth work, how much is building on > that versus doing our own independent thing? We did not refer to the AArch64 PtrAuth work when we devised the Zicfilp mangling scheme, and instead, our foundation was the Itanium C++ ABI. The time at which these 2 mangling schemes appeared were close, and I did not know that AArch64 was developing a similar thing back then, so adapting the Itanium C++ ABI looked like the most practical approach. > Is there any real-world deployment experience from that that we can make use > of? Not that I know of... The AArch64 PtrAuth work is in the main trunk for only less than 1 year, and it may take multiple years for the feature to mature, so I would say that we can surely learn some valuable things from it if we observe it long enough, but for now, I think both schemes are in a similarly nascent status, with the AArch64 PtrAuth scheme being more explicit and controllable. https://github.com/llvm/llvm-project/pull/111661 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
