[PATCH] D89288: [RISCV] Enable the use of the old sptbr name

Jessica Clarke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 19 06:25:51 PDT 2020


jrtc27 added a comment.

In D89288#2338620 <https://reviews.llvm.org/D89288#2338620>, @lenary wrote:

> I think supporting the old CSR names is a small, simple thing that we can do which removes a barrier to people moving to using LLVM rather than GCC. Better this than death by a thousand cuts when people try to move their software over. Yes, people *should* just update their software (and dependencies). The question is will they?

Not if they don't know they have old names in use.

> Yes, I do think at some point we need a more principled approach to CSR naming support, but in the short term, doing so in an ad-hoc manner is fine. I think some kind of warning is a good idea, but LLVM's architecture may not be well set up for that, in all honesty.

We could always have an OldName like we have AltName and emit a warning (maybe optionally an error( in parseCSRSystemRegister if we ever use that to get the CSR. Although currently SysReg's AltName is used exclusively for deprecated names so we could just repurpose that and defer adding OldName until we need both.

In D89288#2337872 <https://reviews.llvm.org/D89288#2337872>, @arcbbb wrote:

> I agree to just fix the code.
> The motivation was that I saw there were two v1.9 aliases added two months ago [1,2],
> and I thought it may be acceptable to add the third one. (sptbr is currently used by pk[3])
> If we are not going to merge this, should the existing aliases be removed as well to make the policy clear?
>
> [1] https://reviews.llvm.org/D78764

This one is for the debug spec which as far as I know has never been ratified, so there's a bit of a difference there.

> [2] https://reviews.llvm.org/D85067

Yeah maybe that one shouldn't have happened, I guess I was in a different mood at the time. But also it's a more niche CSR that's unlikely to matter much either way, whereas people really need to move on from sptbr.

> [3] https://github.com/riscv/riscv-pk/blob/master/machine/minit.c

I mean, all of pk is a pile of legacy stuff people shouldn't be using these days (specifically the pk part of it; bbl is also legacy but less bad). Maybe we're doing our users a service by not letting it build. I know we had to make some build system changes in our fork (that actually break GCC and I really do not care to fix as we don't use GCC) in order to get it to build with a full LLVM-based toolchain, and that was just for bbl (one day we'll move to OpenSBI...).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89288/new/

https://reviews.llvm.org/D89288



More information about the llvm-commits mailing list