Code Monkey home page Code Monkey logo

Comments (20)

aswaterman avatar aswaterman commented on July 25, 2024 1

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.

jrtc27 avatar jrtc27 commented on July 25, 2024 1

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.

ilovepi avatar ilovepi commented on July 25, 2024 1

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.

jrtc27 avatar jrtc27 commented on July 25, 2024 1

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.

kito-cheng avatar kito-cheng commented on July 25, 2024 1

#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.

ilovepi avatar ilovepi commented on July 25, 2024 1

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.

MaskRay avatar MaskRay commented on July 25, 2024 1

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.

kito-cheng avatar kito-cheng commented on July 25, 2024

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.

aswaterman avatar aswaterman commented on July 25, 2024

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.

nick-knight avatar nick-knight commented on July 25, 2024

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.

appujee avatar appujee commented on July 25, 2024

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.

appujee avatar appujee commented on July 25, 2024

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.

appujee avatar appujee commented on July 25, 2024

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

from riscv-elf-psabi-doc.

appujee avatar appujee commented on July 25, 2024

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.

appujee avatar appujee commented on July 25, 2024

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

from riscv-elf-psabi-doc.

asb avatar asb commented on July 25, 2024

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.

jrtc27 avatar jrtc27 commented on July 25, 2024

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

from riscv-elf-psabi-doc.

kito-cheng avatar kito-cheng commented on July 25, 2024

@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.

GP Relax No GP relax
SCS Enable NOT OK OK
SCS disable OK OK

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.

Option 1 Option 2
Used in existing asm code? Yes *1 No
Impact code size Yes, but very minor Yes *2
Break ABI Hard break Soft break compare to option 1

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.

ilovepi avatar ilovepi commented on July 25, 2024

@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.

kito-cheng avatar kito-cheng commented on July 25, 2024

Closed via #371

from riscv-elf-psabi-doc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.