Specify a platform reserved register about riscv-elf-psabi-doc HOT 20 CLOSED

Please quantitatively evaluate the value of the gp register in this context before presupposing that throwing it away is the right thing to do.

from riscv-elf-psabi-doc.

https://reviews.llvm.org/D84414 is the review that contains the x18 choice; see my various comments there on this issue. I agree x18 is entirely unprincipled and wish there had been more willingness to think carefully about what register made sense for SCS.

from riscv-elf-psabi-doc.

I've proposed a change in LLVM doing this, since it would be better to do sooner rather than later. Thankfully the changes are minimal, and there are not likely to be too many users depending of RISCV SCS. https://reviews.llvm.org/D146463

from riscv-elf-psabi-doc.

FYI: Anders Berg mentioned in https://lists.riscv.org/g/sig-toolchains/topic/97736679#544 :

This will and should be covered by one of the upcoming ABI-breaking features where one can reserve some registers for platform related usages. A proposal is on its way in the psABI TG (hopefully during this spring). So please do not rush away with some dirty fix implementations (at least not yet anyway)!

That work has been promised for over a year at this point; blocking changing the shadow call stack ABI on that is not reasonable in my opinion, especially given it is already implemented and in use, just with a potentially bad choice of register. If and when the EABI deviations/whatever it's called these days finally turns up it can be adopted for annotating such binaries to prevent incompatible objects being mixed.

from riscv-elf-psabi-doc.

#371 created for the possibility of using GP, that's also discussed during the EABI/ABI deviations stuffs, so I think sooner or later we will need that.

from riscv-elf-psabi-doc.

We do not want to slow this process down, because it is important that we come to a resolution as soon as possible, but we do want to raise these concerns now, while there is still time to take them into account.

Ideally, projects that place a premium on code size wouldn’t have to forgo code size savings from global relaxation if they want to use SCS, or make use of the platform register. We see no fundamental reason why users in the embedded space who care deeply about code size would not fall into this category, and it would be nice if they could also make use of the feature without being required to drop global relaxation.

As mentioned in the sig-toolchain meeting and the ps ABI issues, there are many benefits to using gp, but before we make a choice we should be sure that we are explicit about the tradeoffs are why we believe they are worth making.

from riscv-elf-psabi-doc.

Note that if the register gp is reserved as a platform register in the platform-independent ABI, it is still possible to reserve one additional platform register in a platform ABI specification. In other words, reserving gp does not preclude also reserving s11 in a platform ABI specification.

from riscv-elf-psabi-doc.

It would be little bit later to reserve a reserved register for RISC-V since the ABI already used for a while, so adding one general reserved register would be annoying to the current ecosystem especially for the linux distro guys...

However here is an evil thought in my mind, GP relaxation might not very useful on non-baremetal environment so we might use that as special use for fuchsia and Android other than GP relaxation, that come with one more advantage is: all existing code base didn't use gp register in program including Assembly codes.

from riscv-elf-psabi-doc.

Android can have a different ABI that reserves a register--perhaps x3 as @kito-cheng mentioned, perhaps something else. Changing the existing Linux ABI to reserve a register is a non-starter.

from riscv-elf-psabi-doc.

As I understand it, this issue is not a request to change the Linux ABI, but to solicit recommendations on minimally disruptive specializations of it. It is understood that this would result in a new, incompatible ABI. Aside from the technical question, there is also the procedural question of how/where to standardize this. I think my suggestion to @appujee to jump-start the discussion here was misguided, and it would be better to start at sig-toolchains.

FWIW, I think the Android folks would be perfectly happy with a nonnormative note in the psABI --- e.g., "variant ABIs that add a platform register are encouraged to throw away GP-relaxation and use x3 for this purpose" --- so they could just point to this to push their LLVM patches through. Of course, it'll eventually be necessary to have an actual spec.

from riscv-elf-psabi-doc.

I think my suggestion to @appujee to jump-start the discussion here was misguided, and it would be better to start at sig-toolchains.

sgtm, i'll start the discussion on sig-toolchain.

FWIW, I think the Android folks would be perfectly happy with a nonnormative note in the psABI --- e.g., "variant ABIs that add a platform register are encouraged to throw away GP-relaxation and use x3 for this purpose" --- so they could just point to this to push their LLVM patches through. Of course, it'll eventually be necessary to have an actual spec.

Yes. It is better to have something that one can point to.

from riscv-elf-psabi-doc.

https://reviews.llvm.org/D84414 is the review that contains the x18 choice; see my various comments there on this issue. I agree x18 is entirely unprincipled and wish there had been more willingness to think carefully about what register made sense for SCS.

agreed with your concerns there. Let me start a discussion on sig-toolchain to address this.

from riscv-elf-psabi-doc.

Emailed: https://lists.riscv.org/g/sig-toolchains/message/544

from riscv-elf-psabi-doc.

FYI: Anders Berg mentioned in https://lists.riscv.org/g/sig-toolchains/topic/97736679#544 :

This will and should be covered by one of the upcoming ABI-breaking features where one can reserve some registers for platform related usages. A proposal is on its way in the psABI TG (hopefully during this spring). So please do not rush away with some dirty fix implementations (at least not yet anyway)!

from riscv-elf-psabi-doc.

makes sense. I've approved the patch https://reviews.llvm.org/D146463 by @ilovepi. Do review when you can.

from riscv-elf-psabi-doc.

Oh I wasn't sure if Anders was referring to the EABI stuff or not. If so, I'm not completely sure it's relevant to this request, but it's hard to tell until there's a full proposal to review.

I agree there shouldn't be too many SCS users and it would be good to change sooner rather than later. I think we should make a little more effort to check for downstream users who may be affected though.

from riscv-elf-psabi-doc.

Well, the EABI stuff has become the same as the ABI deviations stuff, so yes and no.

from riscv-elf-psabi-doc.

@ilovepi thanks for the comment, SCS is kind of special is that eventually will break the ABI (for RISC-V) since that require one extra reserved register, so that give we few more freedom to having more option than other ABI issues.

Of cause the why it become an issue that must did a ABI breakage change is we didn't specify a platform register at beginning, but anyway the boat sailed.

So that's back to the SCS first, I think we have three options:

• Pick a GPR as SCS
• Re-define gp to allow that use other than gp relaxation.
• Use Zisslpcfi extension, that provide dedicated instruction and CSRs to implement SCS.

Pick a GPR as SCS

There are actually two candidate during the discussion x18 and x27, but x18 is kind of many potential issues, so now we are discussion the other candidate, and then x27 has purposed.

x27 obviously better than x18 just like @appujee has listed on the first post.

but it's still has low probability might screwed up in some asm code since it was not reserved before, so I am not prefer to pick up a non-reserved register if possible.

Re-define gp to allow that use other than gp relaxation.

Already listed several reason in #371, so not duplicate here, so just jump to the concern @ilovepi raised, what if user want SCS and gp relaxation, I think it's the most potential drawback of this proposal.

What's the possible solution if people want more code size saving AND SCS?

• Use Zisslpcfi, that would be most simple but require HW support.
• GlobalMerge optimization pass from LLVM*, it could archive similar optimization like gp relaxation, but for local, that should be able to improve by LTO.
• Proposal around the EABI/deviations: using tp as gp (this can be only apply on those system not require thread)

NOTE: * GCC has similar stuffs but called section anchor optimization.

Use Zisslpcfi extension, that provide dedicated instruction and CSRs to implement SCS.

Okay, that should be everyone happy, no extra reserved register needed since the extension has provide dedicated one, the only issue is that require HW has implement that.

Compare

Just drop Zisslpcfi from the comparison table since it's not the point in this thread.

So based on the comparison table and several reason listed in #371, I believe we should go with option 2

*1: google/android-riscv64#78 Android have an issue to tracked where has use the SCS register candidate.
*2: We have some compiler optimization to make up the gap like GlobalMerge optimization, and be noted there is no loss on those system already disable GP relaxation.

from riscv-elf-psabi-doc.

@kito-cheng , Thank you for the summary. I'm pretty confident at this point that we will adopt gp as the platform register, for all the reasons you listed above, in #371, and brought up in sig-toolchain. There are some niceties for using s11, but I think they are outweighed by the benefits of using gp.

As you mention, there may be compiler side work we can do to ameliorate the situation to some extent(i.e., GlobalMerge in LLVM or its GCC equivalent). I think that's probably something we all may want to investigate more: how our toolchains can close any remaining gaps for the tradeoffs we make in the ABI.

from riscv-elf-psabi-doc.

Closed via #371

from riscv-elf-psabi-doc.