Hi,
On Tue, 24 Apr 2018, Alexander Monakov wrote:
> On Tue, 24 Apr 2018, Michael Matz wrote:
> > Well, documentation is both: a description and specification. If we
> > change the documentation now we might not be in the position anymore to
> > change behaviour and docu back because people might in the meanwhile rely
> > on the specification. Which is why documentation changes that promise a
> > certain behaviour are exactly the ones that shouldn't be rushed (even less
> > than actual implementation changes).
>
> My patch isn't making any promises; in a nutshell, it says "must use
> constraints", which is the most tight specification and doesn't open
> any new doors (in contrast with the position that you were arguing,
> which would be a new promise).
>
> Did the other changes in patch 1 look fine to you, content-wise?
Let's see again:
-@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.
+@item Conversely, if the register is a call-clobbered register, making
+calls to functions that use standard ABI may lose contents of the variable.
+Such calls may be created by the compiler even if none are evident in
+the original program, for example when libgcc functions are used to
+make up for unavailable instructions.
+@item Accesses to the variable may be optimized as usual and the register
+remains available for allocation and use in any computations, provided that
+observable values of the variable are not affected.
+@item If the variable is referenced in inline assembly, the type of access
+must be provided to the compiler via constraints (@pxref{Constraints}).
+Accesses from basic asms are not supported.
What is lost here (it wasn't explicit before, but is the case and must
continue to work) is that function calls and returns count as needing the
observable value in the specified register (function calls also count as
setters of them). I think that should be made more explicit. Especially
because you make it explicit that the register remains available for
allocation (where it before said it's not) we need to make sure that
everybody understand that it's only during tiny windows like:
regvar = ...
... code not accessing regvar and containing no calls ...
regvar = ...
The return of functions also must remain making the regvar setter live, to
give us the important parts of the former "stores aren't deleted even if
appearing dead" guarantee.
Ciao,
Michael.
