Comments (20)
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.
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.
@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.
Related Issues (20)
- Collect psABI requirements for next release
- Alignment of __int128 on ILP32 HOT 7
- Question on calculation for HI20 HOT 2
- Question on calculation for HI20 HOT 1
- Clarification of rules for flattening structs containing arrays of empty records HOT 3
- Specify relocation overflow checks HOT 1
- Should calling convention also define ptrdiff_t? HOT 1
- Should we use lw/sw in push pop when we used ILP32, whether it's RV32 or RV64 HOT 3
- Operation semantics of __bf16 datatype HOT 2
- representation of GNU C fixed-size vectors HOT 4
- Deprecate R_RISCV_RVC_LUI? HOT 4
- Define GOT-Relative data relocation HOT 8
- Embedding R_RISCV_RELAX to another relocations HOT 7
- Define gp(x3) as global VLENB HOT 4
- Bitfield integer calling convention garbled
- Calling convention uses RV64GQ without definition or reference HOT 3
- Calling convention description of va_list et al. are unclear HOT 2
- Interpretation of floating-point types
- Linux ABI for Pointer Masking HOT 19
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from riscv-elf-psabi-doc.