On 05/10/2018 03:47 AM, Alexander Monakov wrote: > > > On Mon, 23 Apr 2018, Alexander Monakov wrote: > >> This rewrites global register vars doc to reflect that the register is no >> longer >> reserved exclusively, but in fact is available for general allocation, and >> also >> adds the requirement to properly inform the compiler where inline asms are >> accessing the variable. >> >> This: >> -@item The register is not saved and restored by any functions. >> is reworded to verbosely spell out gotchas related to calls/returns. >> >> * extend.texi (Global Register Variables): Rewrite the bullet list. >> Note that the register is available for allocation. Note that access >> via inline asm must use constraints. Add note about async-signal >> handlers. Remove paragraph about automagic register selection. >> --- >> gcc/doc/extend.texi | 29 +++++++++++++++++++---------- >> 1 file changed, 19 insertions(+), 10 deletions(-) > > Ping? I believe the substance of new text has been hashed out with Michael. > I'd appreciate a review for language and style issues. > > Thanks. > Alexander > >> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi >> index 5571d05d93b..f663741e36c 100644 >> --- a/gcc/doc/extend.texi >> +++ b/gcc/doc/extend.texi >> @@ -9549,11 +9549,21 @@ After defining a global register variable, for the >> current compilation >> unit: >> >> @itemize @bullet >> -@item The register is reserved entirely for this use, and will not be >> -allocated for any other purpose. >> -@item The register is not saved and restored by any functions. >> -@item Stores into this register are never deleted even if they appear to be >> -dead, but references may be deleted, moved or simplified. >> +@item If the register is a call-saved register, call ABI is affected: >> +the register will not be restored in function epilogue sequences after >> +the variable has been assigned. Therefore, functions cannot safely >> +return to callers that assume standard ABI. Whether or not a global register is saved in the prologue and restored in the epilogue is actually a function of the target's prologue/epilogue implementation.
So ISTM this paragraph needs to be refined a bit. Essentially it may or may not change the ABI. It really depends on the target implementation. The rest of the doc changes look fine. jeff
